[cabfpub] Ballot 152 - Issuance of SHA-1 certificates through 2016)

Dean Coclin Dean_Coclin at symantec.com
Tue Oct 20 16:11:38 UTC 2015


Regarding the second matter, the argument appears less convincing because there are no browsers (Microsoft, Apple, Google, Mozilla, Opera) involved. Specifically the question relates to systems that pre-date browser and web PKI environments. These are proprietary device deployments on a massive scale. Think of things like retail terminals and airline kiosks which the owners won’t be able to complete updating before the deadline and hence have requested the capability to continue issuing SHA1 certs in 2016 (all expiring by 12/31/16). 

 

As Chair, I have received several calls/emails from organizations asking why the Forum has jurisdiction over such devices. Of course my answer is because they are rooted in keys that have public trust and such keys should not have been used in this particular application. Nowadays, CAs tell their customers not to use these roots for private applications but we can’t go back in time and re-do things that were done maybe 10 years ago when the foresight wasn’t there.  So this is a real problem these organizations are facing. 

 

 

 

From: Ryan Sleevi [mailto:sleevi at google.com] 
Sent: Monday, October 19, 2015 4:51 PM
To: Dean Coclin
Cc: public at cabforum.org
Subject: Re: [cabfpub] Ballot 152 - Issuance of SHA-1 certificates through 2016)

 

To the first matter, it seems the 2008 paper on exploiting RapidSSL/Verisign should provide adequate background to the issue - https://events.ccc.de/congress/2008/Fahrplan/attachments/1251_md5-collisions-1.0.pdf

 

The issue here is with a chosen-prefix collision, and obtaining a certificate signed with the choice of collision bits. That is, such attacks would primarily affect new issuance, since a new certificate signed with an attacker-chosen set of collision bits would be able to result in being accepted for an attacker-controlled prefix.

 

Given that a number of CAs, and their subCAs, are not properly following the Baseline Requirements requirements with respect to entropy, we cannot presume that entropy alone would be a sufficient mitigation against such an attack.

 

To the second matter, this is simply the traditional ecosystem/first-mover problem. Certainly, the majority of the Browser members in the Forum have significant interest in the ecosystem of WebPKI as a whole (Microsoft has concerns with respect to OS-level communication, Google has concerns with server-to-server communication and the use in non-browser environments such as Google App and Compute Engines, Mozilla has a stated mission concerning the Internet at large, Apple has concerns with non-browser application-level communication, etc). The bifurcation of Browser/non-Browser is thus perhaps a false division. It affects application developers when a browser can't access their site that the application can, as does the inverse. I think the division may be "Organizations that control communications end-to-end" and "Organizations that do not", with Browsers (and those that provide security runtimes) largely operating in that second camp.

 

The problem is one of ecosystem adoption - the 'enterprise' use case of using SHA-1, for example, can lead to language/security runtimes accepting insecure practice, which thus makes the non-enterprise case less secure. Even Browsers are subject to such discussions, as many times they're asked to relax security requirements for "intranet or internal" sites, even when such intranet/internal sites are publicly addressable and reachable. If Browsers relax their security requirements for these sites, they end up relaxing their security requirements for all sites, thus presenting an entire ecosystem security risk. This can be seen in the deprecations of MD5 and RC4, or in the removal of insecure TLS version downgrades to deal with poor enterprise TLS implementations.

 

Thus, as an ecosystem and an industry, the only viable solution that allows all users to be secured is one that moves the entire industry forward, as carveouts and exceptions end up affecting the entirity of the ecosystem. This is ultimately what the CA/Browser Forum is meant to help resolve, by solving the 'first mover' problem by building industry consensus in stakeholders, so that things that proceed in an orderly and phased approach.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20151020/4dbb266b/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5747 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20151020/4dbb266b/attachment-0001.p7s>


More information about the Public mailing list