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/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. _______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
