[cabfpub] Profiling OCSP & CRLs

[Peter Bowen]

Ryan,

This seems reasonable when you are dealing with an online CA. When you are dealing with a root CA, it is currently reasonable to only bring it online once a year to update the CRL, as that is the required frequency.  For many offline CAs it is quite a production to use the HSM, so I think the maximum duration of delegated responder certificates signed by root CAs should be at least a year.

Thanks,
Peter

> On May 8, 2017, at 4:51 PM, Ryan Sleevi via Public <public at cabforum.org> wrote:
> 
> 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 <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 <https://cabforum.org/mailman/listinfo/public>
> 
> 
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170510/6125a696/attachment.html>