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:[email protected]] Sent: Monday, July 10, 2017 3:01 PM To: Jeremy Rowley <[email protected]> Cc: CA/Browser Forum Public Discussion List <[email protected]> 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 <[email protected]> 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:[email protected]] On Behalf Of Ryan > Sleevi via Public > Sent: Monday, July 10, 2017 11:48 AM > To: [email protected] > 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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
