Some points (for the record):
On Thu, Feb 2, 2017 at 7:58 AM, Doug Beattie via Public <[email protected] <mailto:[email protected]> > wrote: 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. 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) * Seems like an overall broad statement. There’s lots of CAs that were working towards SHA-2 migrations and agreed with the timelines set. Not all CAs were opposed to the change. 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. *Note that all the requests came from one CA and not supported by all CAs. I still think the exception process was a mistake, although I understand why the browsers did it. I’d like to point out that for the large part the CAs migrated without exception. 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 ( https://groups.google.com/d/msg/mozilla.dev.security.policy/Htujoyq-pO8/uRBcS2TmBQAJ ) as an example of where adopting the methods from Ballot 169 are critical to the ecosystem. * I think everyone agrees with this, but management teams are concerned about possible patent issues. A lot of CAs participated in the drafting and adoption of the new methods. I don’t think a new ballot to remove method 11 will be controversial once the patent issues are resolved, and I know a lot of CAs are moving towards the accepted 10 methods well before that. 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. * Yeah – this is a good reason. 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. * This is only conjecture. I think CAs don’t want to move away from three year certs because they have customers who want three year certs, not because the market advantages them. Although I do agree there is a lack in automation. Consider the challenges in distrusting a CA - as Google is currently doing for WoSign/StartCom ( https://security.googleblog.com/2016/10/distrusting-wosign-and-startcom.html ). 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. * How distrust is up to the browsers. I don’t think this is a good reason for shorter validity periods. It’s up to Google on how the distrust is enacted. The main reason Google has a hard time distrusting WoSign is the same reason CAs are opposed to shorter validity periods – it affects their customers in a way the customer doesn’t like. 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. * CT is enhanced by longer lived certificates (as the subscriber is more likely to notice something amiss when an issuance occurs). CAA is enhanced only if the entity later changes its CAA record. Seems more of a neutral benefit than a real add-on. 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. 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. * This one has me baffled. Who’s opposed to improving revocation? (Besides the vocal minority who didn’t like short-lived certs.) 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. * Would Google actually start checking revocation using standard CRL processes with shorter lived certs? I’m skeptical. When Google removed CRL checking, it wasn’t the size they complain about the most – it was the performance, the out-of-bands look up, and the reliability of certain CAs. Would Google simple add all certs to their CRLs? 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. * I agree with the fact that validity is a natural revocation. It probably does improve revocation more than any other action the CAB Forum has taken as I don’t think the group has taken very many actions related to revocation. The only ones I can think of are changing it to GET and requiring uptime. 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”. 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. * I think the opposition is more to the fact most customers have not automated sufficiently to make this happen in the timeframe proposed. I’m certainly in favor of shorter validity periods but, so far, I haven’t received much encouragement from our customer-base that this is doable in three months. I’m not sure what failures you’re addressing, but all companies have snafu’s, including Google. Nobody’s perfect but we try to be, and we implement what we find improves security for the community in a manner that web site operators can handle. 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. * Change is scary, but this is a pretty rapid and significant change. What about going to 13 months on a more gradual timeline? Like going to 27 months right away? 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. Frankly, this comes across as an attempt to ignore the many misissuances we're seeing, by artificially delaying discussion. * 13 month validity periods don’t solve mis-issuances. 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. * What about website owners? So far our poll shows they favor two year certs. 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. * So far, the biggest challenge is the lack of automation on the website owner-side to deploy the certificates in a reasonable fashion. This is especially true with large enterprises who have gone through various mergers and acquisitions. They often struggle to move the new company over to their PKI team. Although we offer auto-install tools, the struggle is not with the automated portion on the CA-side of things, but on the internal customer portion. CAA is good first step in speeding migration (and one reason I endorsed the previous ballot).
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
