[cabfpub] Profiling OCSP & CRLs

Mon Jul 10 14:08:15 MST 2017

More of "it would be nice" for OCSP responder certs.  Right now, we run all OCSP through our CA hardware.  Yes - your summary is exactly what I was thinking. We can roll responder certs pretty easily but the signing limit is often hardware-based. Moving to Level 2 hardware gives us more flexibility for large volume, infrequently used certs where OCSP pre-signing doesn't make sense.  Regardless, it's on a future wish list rather than something urgent. 

-----Original Message-----
From: Ryan Sleevi [mailto:sleevi at google.com] 
Sent: Monday, July 10, 2017 3:01 PM
To: Jeremy Rowley <jeremy.rowley at digicert.com>
Cc: CA/Browser Forum Public Discussion List <public at cabforum.org>
Subject: Re: [cabfpub] Profiling OCSP & CRLs

I'm not sure - are you suggesting that the BRs (and/or NetSec
guidelines) allow for that? Or is that more a "Would be nice"?

For the incremental improvement of a normative profile, I'd rather keep the status quo - which I believe already requires the hardware key protection at Level 3 in Section 6.2.7 (but am curious to know if/how CAs have interpreted it otherwise, given the risks).

That said, if we're talking about future system design, I think going to Level 2 does seem reasonable, but will be tricky to work out. As covered in past discussions, we'd still want to see the overall system treated as a High Security target - that is, it should have all the same design and protections around issuance. The preproduction requirement was meant to address this, but to address concerns from some CAs that have a large number of IOT certificates, they wanted to have online responders - which means issuance systems connected to the Internet, which means a much greater risk, HSM or not. I suspect we'd want to see a validity period of something like 14 days (twice that of the maximum permissible OCSP response) - is that what you were thinking?

On Mon, Jul 10, 2017 at 4:47 PM, Jeremy Rowley <jeremy.rowley at digicert.com> wrote:
> A shorter validity period for responders isn’t painful, but could we 
> have a looser interpretation on hardware?  What if delegated responder 
> certs were stored in FIPS 140-2 Level 2 if they were short periods?
>
>
>
> From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Ryan 
> Sleevi via Public
> Sent: Monday, July 10, 2017 11:48 AM
> To: public at cabforum.org
> Subject: Re: [cabfpub] Profiling OCSP & CRLs
>
>
>
> Based on the public discussion, here on the list and on the GitHub, 
> and the private discussions, both off-list and at the CA/Browser Forum 
> F2F in Berlin, I've attempted to update the draft to reflect the discussions.
>
>
>
> To review the overall diff, with inline annotations, 
> https://github.com/sleevi/cabforum-docs/pull/2/files
>
>
>
> To review the difference of those discussions, you can compare with 
> https://github.com/sleevi/cabforum-docs/compare/03d4055ef2a08ad4bdecf9
> aab42440da080b244b...3171d339a9b5ca1e57b77c5175c6ea853f4cf24c
>
>
>
> Here's the summary form:
>
> - From the discussion related to a target of 30/31 days for Delegated 
> OCSP Responders, it is clear that some CAs strongly prefer 
> longer-lived responder certificates, largely due to the operational 
> challenges involved with offline issuance scenarios. To balance that, 
> based on the private discussions had with several CAs regarding their 
> infrastructure, I've attempted to capture this in 4.9.1.2. In short, 
> if a long-lived Delegated OCSP Responder is misused or compromised, 
> the revocation status of all issued certificates is called into 
> question, and since it's not possible to recover from this scenario 
> (such as within 30 days), the only mitigation identified is to fully 
> revoke the issuing CA certificate. This appears to be the standard 
> assumption for several CAs practicing these long-lived responders, and 
> hopefully aligns with their own operational security practices.
>
> - The response lifetime to a subordinate CA is dropped to 3 months 
> (from the existing, implied one year), based on the suggestion of Doug Beattie.
>
> - To account for IOT scenarios raised by some members, the requirement 
> to pre-produce OCSP responses has been relaxed. If you're using a 
> Delegated OCSP Responder (which has a specific technical profile 
> associated with it), and its validity period is less than 31 days, CAs 
> are exempt from the MUST requirement. I'm curious how folks would feel 
> if this date was tightened further - perhaps to 15 days for the 
> Responder - to best balance the risk of an Internet-facing signing 
> system versus the benefit of not requiring a large number of 
> responses. Personally, given the HSMs currently or pending 
> availability, I still strongly believe that pre-producing and 
> distributing responses across-the-board is the best security architecture, but I'm willing to see some of that phased in over time.
>
>
>
> From the discussion, there were some broader points discussed, and 
> from some of the offline discussions, some rather surprising 
> architecture disclosures, so I'm curious on how best to express the following:
>
>
>
> I had thought it clear that, under the current Baseline Requirements, 
> all Delegated OCSP Responder Private Keys were subject to the same 
> requirements as "CA Private Key" - that is, Sections 5.2, 6.1.1.1, and 
> 6.2 absolutely applied. Some CAs indicated that they did not share 
> that interpretation - for example, that it was acceptable to deploy 
> the CA private key directly to their CDN partners, or it was 
> acceptable to maintain a copy of the private key on the disk of the 
> OCSP responder system. I'm curious, more broadly, if the Forum members 
> share that interpretation or have reason to believe it's a desirable 
> property, and if not, where might be appropriate to best clarify this.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4964 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/public/attachments/20170710/c39ccc69/attachment.p7s>