This is getting complicated with all of the interrelated discussions, but here goes. Responses with ** below.
Doug From: Public [mailto:[email protected]] On Behalf Of Jeremy Rowley via Public Sent: Friday, February 3, 2017 2:20 AM To: CA/Browser Forum Public Discussion List <[email protected]> Cc: Jeremy Rowley <[email protected]> Subject: Re: [cabfpub] Draft Ballot 185 - Limiting the Lifetime of Certificates *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. ** Most CAs didn’t have technical issues supporting the change to SHA-256, it was that customers consuming the certificates were not properly educated on the dates or didn’t understand that this change would be applicable to them. 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. ** Again, this is the CAs being a proxy for their customers and not a CA technical issue regarding the deprecation of SHA-1 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. ** I think there things we can do to address this concern other than changing the validity period. Would running all SANs of active certificates through CAA within X months of the ballot help elevate this? Any that failed could be addressed in some way (to be agreed to). ** I think most CAs verify the domain as part of issuance for DV (at least is seems that is the case for GoDaddy), thus the limit of “bad” certificates is 3 years, not 6 in most cases. Is that acceptable? ** Want to reduce the lifetime of Domain validation reuse for DV certificates to something less than 3 years, Sure, I’m all for that. 6 months? 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. ** Or they are in CT logs or whitelisted by the browsers that enforce the rules, or… There are going to be cases where existing certificates stop working (1024, SHA-1 and others), so that’s life. I don’t think that needs to drive the shortening of the validity period. In fact, I’d be OK with making it a requirement that if you issue certificates longer than 16+- months that you must notify the subscriber that you cannot guarantee that the certificate will be useable for that full time due to changes in the BRs. Place the risk back on the user. 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. ** You’re making claims that validity periods are the root cause of non-automation. Do you have data to back up this claim? I vehemently object to your claim that CAs are artificially constraining the market to take advantage of users, seriously Ryan, really? CAs provide a service to web site administrators to provision certificates. If they want to use APIs, plugins they can. If they want to request it manually they can, but we’re certainly not working with Apache or nginx to encourage manual certificate issuance as the preferred method. ** Let’s Encrypt has been promoting automation, and that’s great, it’s catching on. But, when it’s free and there is no billing or support for certificates that assert Identity, it’s easy to automate. EV is not so easy to automate. We should not be aligning rules to benefit one segment of CAs, in this case the Free CAs like LE 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. ** I agree with Jeremy, this is not a BR thing and not related to certificate validity periods. If you need to distrust a CA then you should. Driving down the validity period so it’s easier for root store operators to terminate CAs should not be a driver in this decision. 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. ** I think we can help meet those goals. Some CAs are doing CT for DV certificates now, others will all certainly align shortly (by October for sure). Want CAs to do a mandatory CAA check on issued certificates at some point and resolve discrepancies? That might be possible, and more widely accepted than reducing the validity period. Let’s look for ways to address you concerns other than jumping to the conclusion that 1 year certificates will solve all the problems. ** It’s my understanding that there are very few CAA records (haven’t checked recently), so I’m not sure how useful a wide check would be. I’m also not convinced Google has CAA configure correctly. I thought Google issued all of their SSL certificates from the Google Internet Authority G2 CA which is run by Google. If that’s the case, why is the CAA record configured to symantec.com instead of google.com? I realize the root is GeoTrust (Symantec), but the CA issuing the certificates should be looking for google.com. configured correctly. Just a side note… I’m probably wrong. 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.) ** If short lived certificates do not require revocation services, then that might be a way to encourage wider adoption. I’m not opposed to issuing shorter validity certificates, but we still have customer segments that need multi-year certificates to save time and money. 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. ** I’m sorry, but I don’t see how 1 year certificates helps substantially improve the security of the webPKI over 3 year certificates. If the cert is 1 year vs. 3 is there a difference? If we were talking about 4-7 day certificates, then I agree, there are real benefits. 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. ** CAs are not resistant to change generally, but they are when there is an impact to customers or business. I think we’ve beaten the SHA-1 deprecation topic to death, that delay and outcry was the CAs advocating for their customers, not complaining that it would be hard to set up new CAs and issue certificates with a different signing algorithm – that was easy. 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. ** Agree with Jeremy, short validity won’t help reduce misissuance. 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. ** We need to bring the web site administrators into this discussion. 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). ** As the person proposing the ballot, the onus on building a case should be on you to convince web site owners, CAs, Browsers and other relying parties that this is beneficial. What are the concrete reasons that 27 or 39 month certificates *are* harmful? You’ve made a lot of points in this email and there have been a number of valid responses. Certainly there are some benefits to shorter validity certificates, but at what cost to the overall ecosystem? I think we need to tally, track and document these exchanges in a better medium than an email list and bring in the other members of the ecosystem to comment. ** Is there room for a longer validity period certificate with certain OIDs or other contents that could be used to by those that *need* then as long as certain periodic re-validation is performed and asserted publicly? <don’t know what or how, just an idea>
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
