<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 2, 2017 at 7:58 AM, Doug Beattie 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-US">
<div class="gmail-m_4534562038403751165WordSection1">
<p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:calibri,sans-serif;font-size:11pt">I don’t understand this how this is the “single greatest impediment towards improving the security of the Web PKI” or how misissuance decreases with shorter validity
 periods.  While the SHA-1 deprecation was difficult, this primarily was driven by customers technical ability to give up SHA-1 and not with the technical ability of the CAs to change over. </span></p></div></div></blockquote><div><br></div><div>I'm surprised to hear you say that, Doug, given how long the deliberations took for SHA-1 (and ultimately involved browsers having to act unilaterally, because CAs opposed change)</div><div><br></div><div>For example, consider the (many) SHA-1 exception requests. A shorter certificate lifetime would have allowed for a more nuanced phase-out, and customers (such as Symantec's) could have been better informed of the SHA-1 deprecation - through the natural process of certificate expiration. We could have surfaced these issues considerably faster, and thus avoided (or reduced) the need for an exception process.</div><div><br></div><div>Consider the impact of Ballot 169 (or whatever its future form may be). Browsers and relying parties *cannot* be assured that the certificate is not unauthorized for another 78 months (at least! - assuming we can get improvements), due to the combined use of previously validated data and long lived certificates. This is, simply put, unacceptable. GoDaddy's recent misissuance ( <a href="https://groups.google.com/d/msg/mozilla.dev.security.policy/Htujoyq-pO8/uRBcS2TmBQAJ">https://groups.google.com/d/msg/mozilla.dev.security.policy/Htujoyq-pO8/uRBcS2TmBQAJ</a> ) as an example of where adopting the methods from Ballot 169 are critical to the ecosystem.</div><div><br></div><div>Consider any reform about extensions and their content - again, the ecosystem of relying parties and browsers cannot rely upon those changes being effective until they're forced to either a) break users or b) they naturally expire.</div><div><br></div><div>Consider how the long validity period of certificates has artificially suppressed the need for automation, making it more difficult, rather than easier, for customers to obtain certificates - because they only need to do it once every 3 years. And while being sensitive to our antitrust policy, I cannot help but think opposition to one year certs is, in part, motivated by CAs trying to artificially constrain the market in ways that advantage them, because their customers are much less likely to look at their competitors if they only look once every three years (... or 6), rather than every year.</div><div><br></div><div>Consider the challenges in distrusting a CA - as Google is currently doing for WoSign/StartCom ( <a href="https://security.googleblog.com/2016/10/distrusting-wosign-and-startcom.html">https://security.googleblog.com/2016/10/distrusting-wosign-and-startcom.html</a> ). Shorter-lived certificates ensure the ecosystem is more robust and resilient to changes in trust stores, and in turn creates greater incentives for CAs to abide by the Baseline Requirements that they've developed.</div><div><br></div><div>These are all considerable improvements to the natural state of security. Improvements like CAA or CT simply don't work meaningfully, so long as certificates are allowed to be valid for 39 months and reuse cached validation for 39 months. Imagine how much more secure the ecosystem could be if, within a year, we could be assured that every CA would have checked the CAA record and disclosed via CT.</div><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"><div lang="EN-US"><div class="gmail-m_4534562038403751165WordSection1">
<p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)">If there are significant numbers of certificates with invalid/outdated DN information then we need to address this (is this true?), but that does not necessarily
 mean short validity certificates or shorter re-use periods.  Further, when we find such certificates, regardless of validity period, they need to be revoked and the revocation status needs to be respected by the Web PKI.  Today the revocation process is broken.</span></p></div></div></blockquote><div><br></div><div>I wholeheartly agree that the revocation process is broken, but so far, CAs have largely opposed improvements. I'm incredibly grateful that GlobalSign supported Ballot 153, which would have seen an incredibly useful introduction of a means to solve that problem, but it's also clear that not all CAs share your awareness or attention to resolving the revocation problem.</div><div><br></div><div>It's also important to consider that shorter-lived certs create the opportunity to make CRLs *more* viable and performant, which might be able to see their reintroduction in the WebPKI. A significant challenge to the CRL problem has been the fact that many (too many) CAs have deployed their CRLs incredibly inefficiently. By allowing shorter expiration, we allow CRLs to be smaller, and thus improve the security of the ecosystem by making them more reliable. I'll note that this isn't a perfect solution - there are still other normative requirements needed to reform CA's practices, since too many have trouble reading or understanding their business or RFC 5280 - but it's an important step into making these more viable.</div><div><br></div><div>But even in the absence of CRLs, the validity period of a certificate represents a natural revocation, so surely you can see how supporting this helps _improve_ the revocation story on the Web, more than any other action CAs or the CA/B Forum has taken to date.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_4534562038403751165WordSection1">
<p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)">As Dean said previously, this was discussed without resolution a while ago and I haven’t seen consensus or constructive discussions on recent proposals to change
 either the maximum validity period or re-use of vetting data.  Assigning across the board values for max validity and vetting data is shortsighted.  These should be set based on risk and business processes and not “being consistent for the sake of being consistent”,
 or “making Web PKI more secure”.</span></p></div></div></blockquote><div><br></div><div>It's understandable that CAs would be opposed to things that represent change. If anything, the activity of the Forum for the past 4 years - and the considerable and numerous failures of the CAs participating (_especially_ the failures of the CA Security Council membership, which is both ironic and disappointing) - has shown that the most meaningful way to make changes - such as SHA-1 deprecation - ultimately require making concrete action rather than endless deliberations.</div><div><br></div><div>I realize we don't have a perfect solution, because there will always be CA members who oppose change because they're either afraid to adapt or unable to, but as we look to move more of the Web to HTTPS, it's simply necessary that we take steps to ensure the ecosystem can move forward in a timely way and that we take concrete steps to improve security.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_4534562038403751165WordSection1">
<p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)">We must understand the issues we’re trying to solve and come up with an approach that is acceptable to TLS customers, CAs, Root programs and balance security
 with usability vs. applying a blanket 13 max across all certificate types “just because”.  I’d propose that this be taken up in a working group where the necessary discussions and requirement gathering can be done.</span></p></div></div></blockquote><div><br></div><div>Frankly, this comes across as an attempt to ignore the many misissuances we're seeing, by artificially delaying discussion.</div><div><br></div><div>We know that CAs are opposed to changes or supportive of longer certs (by the large majority, as our strawpolls saw). We know that browsers have, to date, expressed support for shorter certificates.</div><div><br></div><div>At this point, we need to establish concrete reasons why 13 months is harmful or insurmountable. I haven't seen any such reason yet for 13 months - although the discussion of the challenges with 12 months was incredibly useful and informative - and I would hope that if such reasons exist, CAs would and could be bringing them to the Forum. </div></div></div></div>