[cabfpub] FW: Ballot - expiration of SHA1 certificates

[Erwann Abalea]

Le 08/09/2014 14:45, Gervase Markham a écrit :
> On 08/09/14 13:24, Erwann Abalea wrote:
>> The problem with SHA1 is its low collision resistance. It's a problem
>> with signed objects if the applicant can be hostile (certificate
>> request, signed document, timestamp, ...). A subordinate CA, if owned
>> and operated by the same entity as the issuing CA, isn't hostile.
> A fair point. However, intermediate certificates tend to live longer
> than end-entity certificates, so the risk of continued issuance even
> without a potentially hostile applicant is more uncertain.

Consider this hierarchy:
Root (30 years, SHA-whatever)
   -> CA1 (25 years, SHA1)
     -> subscribers (3 years, SHA1 then SHA256)

The fact that CA1 has a certificate with some SHA1 in it (issued by the 
Root) has no impact on the hash this CA uses to sign subscriber 
certificates (is it what you designate as "continued issuance" in your 
phrase?). CA1 can switch to SHA1-signed subscriber certificates when 
necessary, without changing its own certificate.

> Is there anything which breaks under the new SHA-1 rules which would
> _not_ break if it was permitted to issue SHA-256 EE certs from a SHA-1
> intermediate?

AFAICT, no. Maybe browsers/servers on other platforms (gaming consoles, 
WebTV, routers, ...)?


Still playing.

We know the risk of using SHA1 for signature *generation*: collisions. 
This risk applies to any content provided by a potential adversary, the 
collision has to be built before the content is submitted to the CA. 
Subscriber certificates are proved targets, maybe on-the-fly generated 
OCSP responses, but not pre-generated OCSP responses, not subordinate CA 
certificates, and not CRLs.
Once the signature is done (using SHA1), the risk is a preimage one, and 
SHA1 isn't concerned so far.

I'm fine with dictatorial decisions if they go my way. That's why I'm 
fine with a complete removal of SHA1 for every signed object (certs, 
OCSP, CRLs, timestamps, documents, ...).
But I prefer analysis and risk management driven decisions, if possible. 
If risk management tells us that SHA1's resistance to preimage can't be 
trusted, ok, let's switch everything to SHA2: all signatures, but also 
PRF used in TLS<1.2, entropy pools in OS and libraries, maybe entropy 
filtering on HSMs, other?

Another concern regarding SHA1 and signatures is SSL/TLS and its use of 
MD5+SHA1 combination for signature (until TLS1.2). Ryan Sleevi proposed 
to add colors depending on TLS version used 
(https://twitter.com/sleevi_/status/507966405119995904).

-- 
Erwann ABALEA