<div dir="ltr">Customer demand for 2+ year certificates is probably the least important signal to consider. Customers want long-lived certificates so they can worry about them less, and support manual workflows. But that's not a security benefit, and the role of the Baseline Requirements (and the CA/B Forum) isn't to optimize for meeting customer demand -- it's to improve internet security.<div><div><br></div><div>Whether or not customers can tolerate and adapt to shorter certificates is a more reasonable question. And a maximum of 1 year seems very much like something enterprises should be able to tolerate, even if they don't like it. And the data posted here so far suggests that plenty of significant customers do know how to tolerate using 1 year certificates.</div><div><br></div><div>You can still do manual certificate management on a 1 year cycle. What you can't do is stick a certificate somewhere and forget where it is until it's time to panic, and that's a good thing. If enterprises experience 1-year limitations as pain, that's pain they should start experiencing as soon as possible.</div><div><br></div><div>This ballot (to me, anyway) came out of nowhere without any prior discussion focused on a potential ballot, and it's a big change from the status quo on the CA side, so I can understand why it's caused a strong reaction. </div><div><br></div><div>But my reaction to seeing this ballot pass would be great relief -- not just for making future deprecation cycles take less long, and not just to minimize damage from compromised certificates when revocation is clearly unenforceable in any meaningful way at scale today (regardless of Chrome's behavior) -- but because it would meaningfully push enterprises towards a more responsible baseline of infrastructure management.</div><div><br></div><div>-- Eric</div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 3, 2017 at 5:37 PM, Ryan Sleevi 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"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Fri, Feb 3, 2017 at 4:35 PM, Geoff Keating <span dir="ltr"><<a href="mailto:geoffk@apple.com" target="_blank">geoffk@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Weren’t most of the long-lived certificates that caused problems those issued before the current limit of ~3 years?  </blockquote><div><br></div></span><div>Nope, not in our experience. I'm hoping Jody can share his graph, but much of our 'breakage' experience was from sites where the CA waited to stop issuing SHA-1 certs until it was explicitly forbidden - that is, they did not even default to SHA-256, or made it considerably *more* difficult for their customers to obtain SHA-256 signed certs.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In particular:<br>
<br>
- A 10-year certificate issued right before the BRs were adopted would expire 30 June 2022<br>
- A 5-year certificate issued when special circumstances were allowed, could expire 31 March 2020<br>
- The no-SHA-1 requirement came into force January 2015, and may have been a little rushed (or, really, should have been done sooner so that the hurry wasn’t necessary)<br></blockquote><div><br></div></span><div>The no-SHA-1 requirement came in force January 2016 - not 2015. We passed the Ballot in 2015, following Microsoft's announced deprecation in Nov 12, 2013 - <a href="https://technet.microsoft.com/en-us/library/security/2880823.aspx" target="_blank">https://technet.microsoft.<wbr>com/en-us/library/security/<wbr>2880823.aspx</a></div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">So it seems to me this point is addressing a problem that has already been mostly solved; there’s a big difference between waiting 7 years to do something, and being able to do it in 3 years.  As we’ve seen, it appears that once you’re down to about 2 years, the limiting factor is not certificate expiry but getting the rest of the Internet to catch up.<br></blockquote><div><br></div></span><div>Except we're not down to 3 years (or 2). For domain validation at present, we're at 6.5 years. Reducing to two years only gets us to 5.5 years. I think our ideal target should be O(months), and while it'll take the industry - CAs and vendors alike - to get there, it's possible if we take it seriously.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
As for revocation, I believe it is a problem that can be solved, and even if it can't, it does not really motivate a reduction to 1 year; you would need to go to 1 week or similar.  This is a much longer discussion than I can have here.<br></blockquote><div><br></div></span><div>Right, I believe it's a *necessary* condition to move to shorter certificates, but not a *sufficient*. We know short-term certificates (which, regrettably, some CAs opposed) offer one viable path, but we also know that if we want to see more of the Web move to HTTPS, and we want to see CRLs become viable (for their significant privacy and efficiency gains), then we also need a series of checks and balances to limit CRL growth. Expiration is but one aspect (of many) to that, but even if we don't solve that problem quite yet, we can at least acknowledge the net positive to the problem.</div></div></div></div>
<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>
<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></div></div></div>