[cabfpub] Profiling OCSP & CRLs

Jeremy Rowley jeremy.rowley at digicert.com
Mon Jul 10 13:47:46 MST 2017


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/03d4055ef2a08ad4bdecf9aab42440da080b244b...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 --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170710/465ffd14/attachment.html>
-------------- 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/465ffd14/attachment.p7s>


More information about the Public mailing list