<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Ryan,</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Peter</div><br class=""><div><blockquote type="cite" class=""><div class="">On May 8, 2017, at 4:51 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=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div dir="ltr" class="">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?<div class=""><br class=""></div><div class="">Or were you suggesting 30 as a SHOULD, 45 as a MUST, which in practice means... well, 45? :)</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Apr 27, 2017 at 12:57 PM, Curt Spann <span dir="ltr" class=""><<a href="mailto:cspann@apple.com" target="_blank" class="">cspann@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;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 class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="h5"><div class="">On Apr 25, 2017, at 4:53 PM, Ryan Sleevi via Public <<a href="mailto:public@cabforum.org" target="_blank" class="">public@cabforum.org</a>> wrote:</div><br class="m_8726925205798228250Apple-interchange-newline"></div></div><div class=""><div class=""><div class="h5"><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" target="_blank" class="">https://github.com/sleevi/<wbr class="">cabforum-docs/pull/2/files?<wbr class="">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></div></div>
______________________________<wbr class="">_________________<br class="">Public mailing list<br class=""><a href="mailto:Public@cabforum.org" target="_blank" class="">Public@cabforum.org</a><br class=""><a href="https://cabforum.org/mailman/listinfo/public" target="_blank" class="">https://cabforum.org/mailman/<wbr class="">listinfo/public</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></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=""></body></html>