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

[Bruce Morton]

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<mailto: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<mailto: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<mailto: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/da4c72c2/attachment-0003.html>