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

[Ryan Sleevi]

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: https://cabforum.org/pipermail/public/attachments/20151019/3cb83184/attachment.html