<div dir="ltr">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><br></div><div>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><div class="gmail_quote">On Thu, Apr 27, 2017 at 12:57 PM, Curt Spann <span dir="ltr"><<a href="mailto:cspann@apple.com" target="_blank">cspann@apple.com</a>></span> wrote:<br><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">Hi Ryan,<div><br></div><div>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><br></div><div>Cheers,</div><div>Curt</div><div><div><br><blockquote type="cite"><div><div class="h5"><div>On Apr 25, 2017, at 4:53 PM, Ryan Sleevi via Public <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>> wrote:</div><br class="m_8726925205798228250Apple-interchange-newline"></div></div><div><div><div class="h5"><div dir="ltr">Hi folks,<div><br></div><div>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><br></div><div>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">https://github.com/sleevi/<wbr>cabforum-docs/pull/2/files?<wbr>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><br></div><div>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><br></div><div>If people find this approach useful, I'd like to also reform the CRL profile in a similar fashion.</div><div><br></div><div>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>_________________<br>Public mailing list<br><a href="mailto:Public@cabforum.org" target="_blank">Public@cabforum.org</a><br><a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/<wbr>listinfo/public</a><br></div></blockquote></div><br></div></div></blockquote></div><br></div>