[cabfpub] [EXTERNAL]Re: Profiling OCSP & CRLs

Tue May 9 19:27:10 UTC 2017

Great. That's exactly the sort of discussion I think we want to have. I
know there's a few other CAs that have privately reached out, so you're not
alone, and perhaps your (public) response here will help encourage them to
comment :)

Granted, it's important to consider that if a CA is compromised, we have a
way to deal with that - revocation. Delegated responder certificates don't
have that. That's called out with
https://tools.ietf.org/html/rfc6960#section-4.2.2.2.1 , with the issue that
checking CRL DP for responder certificates is, for better or worse,
defeating considerable value in OCSP to begin with.

This is where the 30 day window comes from - trying to understand how to
effectively and reasonably mitigate the issue, since this is fundamental in
any trust system (c.f. Kerberos for an alternative, non-WebPKI example for
addressing this)

Similarly, figuring out how to objectively evaluate the security of those
responders. Your HSM is great, but if, for example, your responder is
live-signing requests (e.g. to support nonces), then the HSM itself doesn't
add value to the security properties, since you could compromise the
'signing platform' to mint an arbitrary number of responses (e.g.
thisUpdate/nextUpdate rolling windows). That may sound somewhat
academic/extreme, but CAs already leverage this capability (in what I would
argue is insecurely) to pre-generate blocks of OCSP "Good" responses for
weeks at a time. That's also what this profile tries to address/correct.

To spin the discussion around a little - what were the factors that lead
you to design your system like this? Does it apply to all of your
responders, or just your responders-for-intermediates? If the profile only
applied to responders-for-leaves(and-TCSCs), does that change your
thoughts? What were the design factors you were trying to account for, so
we can see either how to design them into the profile, or find an 'end
goal' that might account/allow for these?

On Tue, May 9, 2017 at 2:35 PM, Bruce Morton <
Bruce.Morton at entrustdatacard.com> wrote:

> Would like to discuss OCSP Responder certificate validity.
>
>
>
> The BRs do not discuss how OCSP systems should be operated. It would
> appear that a short validity period would be to mitigate against a low
> security policy on the OCSP responder and keys.
>
>
>
> In our case, we manage the OCSP responder similar to an issuing CA. The
> responder is in a secure zone and the keys are protected on a FIPS 140-2
> Level 3 HSM with M of N controls. Since the keys perform a function which
> the CA could perform, we treat the keys in the same manner as a CA. As
> such, if the OCSP key is compromised, then the CA is also compromised and
> CA certificate revocation would be required. In this case, I do not think
> that a 30 (or 45) day upper-bound validity is required. We currently use 3
> years, but it could be argued that the validity period could be even longer.
>
>
>
> Thanks, Bruce.
>
>
>
> *From:* Public [mailto:public-bounces at cabforum.org] *On Behalf Of *Ryan
> Sleevi via Public
> *Sent:* Monday, May 8, 2017 7:52 PM
> *To:* Curt Spann <cspann at apple.com>
> *Cc:* Ryan Sleevi <sleevi at google.com>; CA/Browser Forum Public Discussion
> List <public at cabforum.org>
> *Subject:* [EXTERNAL]Re: [cabfpub] Profiling OCSP & CRLs
>
>
>
> I think 30 days is what we should target as the upper-bound, so would that
> be suggesting that we should target 15 days as a SHOULD with 30 as a MUST?
>
>
>
> Or were you suggesting 30 as a SHOULD, 45 as a MUST, which in practice
> means... well, 45? :)
>
>
>
> On Thu, Apr 27, 2017 at 12:57 PM, Curt Spann <cspann at apple.com> wrote:
>
> Hi Ryan,
>
>
>
> Regarding delegated OCSP responder certificate validity, if 30 days is a
> desired goal (or a similar timeframe), I would recommend 45 days to allow
> the renewal to occur every 30 days, with a 15 day buffer for operational
> issues. Basically, for whatever target validity period we should add some
> buffer time.
>
>
>
> Cheers,
>
> Curt
>
>
>
> On Apr 25, 2017, at 4:53 PM, Ryan Sleevi via Public <public at cabforum.org>
> wrote:
>
>
>
> Hi folks,
>
>
>
> In response to various investigations about OCSP performance, operation,
> and trying to figure out how we can move to a world of more ubiquitous OCSP
> stapling, one of the things that comes up is that OCSP responses are very
> much like the pre-BR wild-west of certificates.
>
>
>
> I've tried to capture a starting point for discussion at
> https://github.com/sleevi/cabforum-docs/pull/2/files?diff=split . I've
> tried to annotate the changes, and the reason for the changes, so that
> people can understand them, their goals, and the implications.
>
>
>
> While I'd like to get this to the point of a Ballot, it's not quite there
> yet. In particular, it doesn't state Effective Dates, because I want to get
> a sense of the challenges that each bit may pose :)
>
>
>
> If people find this approach useful, I'd like to also reform the CRL
> profile in a similar fashion.
>
>
>
> There's also a lot of ways to express these requirements. I considered
> using a table approach, which I suspect some of our ETSI-audited CA members
> will be familiar with, and which I find useful, but I thought it best to
> keep the initial discussions simple and textual, and then we can make it
> pretty once we're happy with the substance.
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170509/8b9086cb/attachment-0003.html>