<div dir="ltr"><div class="gmail_extra">Right, as I mentioned, this didn't attempt to start the discussion (related to CRLs) yet, but I do think we want to revisit this aspect as well, ideally in trying to find out the end goal for the security standards, so then we can work out the process and timeline to get there.</div><div class="gmail_extra"><br></div><div class="gmail_extra">That is, put differently, do we think it's reasonable that a CRL (with it unrevoked) could be reused for 11 months and 25 days after an intermediate has been revoked? Even if the 'new' CRL is created with it revoked, it can be replayed.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 10, 2017 at 1:09 PM, Peter Bowen <span dir="ltr"><<a href="mailto:pzb@amzn.com" target="_blank">pzb@amzn.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"><div>Ryan,</div><div><br></div><div>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><br></div><div>Thanks,</div><div>Peter</div><div><div class="h5"><br><div><blockquote type="cite"><div>On May 8, 2017, at 4:51 PM, Ryan Sleevi via Public <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>> wrote:</div><br class="m_3298826987035680277Apple-interchange-newline"><div><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="m_3298826987035680277h5"><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_3298826987035680277m_8726925205798228250Apple-interchange-newline"></div></div><div><div><div class="m_3298826987035680277h5"><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/c<wbr>abforum-docs/pull/2/files?diff<wbr>=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/l<wbr>istinfo/public</a><br></div></blockquote></div><br></div></div></blockquote></div><br></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></div></blockquote></div><br></div></div>