<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 24, 2017 at 10:51 AM, Gervase Markham <span dir="ltr"><<a href="mailto:gerv@mozilla.org" target="_blank">gerv@mozilla.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">My assumption here is that they key date is the one when the last<br>
"39-month" cert expires, and so all certs in existence are of the new,<br>
shorter length. If we (unrealistically) made a change to 13 months<br>
tomorrow, that would be 24th May 2020.<br></blockquote><div><br></div><div>At least for Chrome, I cannot state that assumption is fair/correct.</div><div><br></div><div>Your assumption relies on there being no issues. My operating model is there will be CA issues in the course of the next three years that will necessitate invaliding certificates issued today (and up to that 'period')</div><div><br></div><div>Note that this is not the _only_ objection to staggering, but it merely clarifies why your operating assumption is not accurate.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If we say "we will move straight to 13 months", then it might be a year<br>
(say) before we could institute such a change. That would make the key<br>
date 24th May 2021.<br></blockquote><div><br></div><div>As stated above, that's the date if nothing bad happens in the ecosystem. It will, however, so that's not the key date.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So there is a possible benefit in a 2-phase approach - we get where we<br>
want to be quicker. But if CAs feel that the complexity of having two<br>
phases is more than it's worth, then the idea won't fly.<br></blockquote></div></div></div>