<div dir="ltr"><div>To #2, I think that it is reasonable to ask for installation to be performed every year, and especially when it feels the most *unreasonable* to the user. This isn't meant to be ideological punishment for not automating -- it's that the systems for which certificate rotation causes the greatest pain are also likely to be the systems for which algorithm rotation (or protocol rotation, etc.) causes the greatest pain. In other words, making certificate rotation more frequent is mostly going to pain the people you were going to be arguing with anyway in the months after the first major SHA-2 weakness is published.<br></div><div><br></div><div>There's also the possibility of doing this in laddered stages. You could imagine a ballot which sets a 26-month limit for a year, and then a 13-month limit which takes effect the year after that. That provides a generous adjustment timeline for enterprises, but a clearly stated direction by the Forum which provides both short- and long-term benefits. It might also just feel less jarring to customers, which makes everyone calmer.<br></div><div><br></div><div>-- Eric</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 7, 2017 at 12:15 AM, Peter Bowen via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
We have had 50+ messages in the threat on the ballot proposal from Google but it seems like it has gone somewhat off course and gotten stuck on a tangent.<br>
<br>
Going back to the original topic, I think there is a lack of clarity on why this is being proposed.  Ryan Sleevi, in an email in the thread, provided some links to older emails.  Many of them were from before I was involved with the Forum, so I went back and read through them.<br>
<br>
Back in <a href="https://cabforum.org/pipermail/public/2013-November/002493.html" rel="noreferrer" target="_blank">https://cabforum.org/<wbr>pipermail/public/2013-<wbr>November/002493.html</a>, Gerv wrote:<br>
<br>
"The problem with long-life certs is not any of the above; it's the<br>
reduced agility of the certificate system as a whole. Every time we make<br>
an improvement, we have to wait 5 years and 3 months before we can rely<br>
on every certificate having been issued under the new rules or with the<br>
new feature. That's too long."<br>
<br>
Since then certificates have been limited to 39 months, so that time has gone down somewhat.  Assuming CAs require at least three months notice for changes (and I think most of us would like more than than), the delay between approving a change and it being universally deployed is three and a half years.  Assuming we all agree that subscribers expect the certificates they already have to continue to work until they expire, then the only way to increase the rate of change is to reduce the maximum duration of validity.<br>
<br>
Ryan's email from last week echoes what Gerv said 3+ years ago.  Ryan wrote:<br>
<br>
"The validity period of certificates represents the single greatest impediment towards improving the security of the Web PKI. This is because it sets the upper-bound on when legacy behaviours may be safely deprecated, while setting a practical lower-bound for how long hacks and workarounds need to be carried around by clients."<br>
<br>
I think the real question here is whether we, as the Forum, think that the current state of things is such that having a 3.5 year (or longer) deprecation period is acceptable or whether this number needs to come down to something much shorter.  My inference from reading Ryan's emails is that Google thinks that sixteen months is about the longest that any deprecation period should last and, of that time, the concept to GA/stable release cycle for CAs should take no longer than three months.<br>
<br>
The real questions, in my mind are:<br>
<br>
(1) How long is reasonable for taking something from concept to production?<br>
<br>
(2) What is the longest reasonable deprecation window?<br>
<br>
To find one possible answer to #1, I looked at the Chromium release schedule.  The standard there is 54 days (about 8 weeks) from branch to stable.  Any time to handle "intent to implement"/"intent to ship" and actually implement the code is before this window.  I know many dev teams use two week "sprints" for planning and are usually booked at least a couple of sprints ahead, so let's call this six weeks.  Based on this, I would say the minimum reasonable period for concept to production should be about 14 weeks.  This assumes a very aggressive release cycle.  It does not take into account that many CAs are using third party software, which means that integration time will be needed if code changes are required -- call this another eight weeks of planning, testing, and migration.  So 22 weeks is probably the shortest reasonable answer for #1.<br>
<br>
I think the answer to #2 is the lynchpin.  Certificates can be quite complex to install on some systems, frequently requiring downtime of the system.  How often should this be required?<br>
<br>
Thanks,<br>
Peter<br>
______________________________<wbr>_________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" rel="noreferrer" target="_blank">https://cabforum.org/mailman/<wbr>listinfo/public</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><a href="https://konklone.com" target="_blank">konklone.com</a> | <a href="https://twitter.com/konklone" target="_blank">@konklone</a><br></div></div></div></div></div></div></div>
</div>