<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Ryan,<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Cheers,</div><div class="">Curt</div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Apr 25, 2017, at 4:53 PM, Ryan Sleevi via Public <<a href="mailto:public@cabforum.org" class="">public@cabforum.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi folks,<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">I've tried to capture a starting point for discussion at <a href="https://github.com/sleevi/cabforum-docs/pull/2/files?diff=split" class="">https://github.com/sleevi/cabforum-docs/pull/2/files?diff=split</a> . I've tried to annotate the changes, and the reason for the changes, so that people can understand them, their goals, and the implications.</div><div class=""><br class=""></div><div class="">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 :)</div><div class=""><br class=""></div><div class="">If people find this approach useful, I'd like to also reform the CRL profile in a similar fashion.</div><div class=""><br class=""></div><div class="">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.</div></div>
_______________________________________________<br class="">Public mailing list<br class=""><a href="mailto:Public@cabforum.org" class="">Public@cabforum.org</a><br class="">https://cabforum.org/mailman/listinfo/public<br class=""></div></blockquote></div><br class=""></div></body></html>