[cabfpub] Profiling OCSP & CRLs

Ryan Sleevi sleevi at google.com
Mon Jul 10 14:01:01 MST 2017


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/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.


More information about the Public mailing list