[cabfpub] FW: Ballot - expiration of SHA1 certificates

[Ryan Sleevi]

On Mon, Sep 8, 2014 at 10:34 AM, Erwann Abalea <erwann.abalea at opentrust.com>
wrote:

>
> 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?
>

The decision here is more pragmatic than anything. From an API maintainer
side, and from a browser vendor, I have no way of knowing whether or not
the data in CA1 was supplied by an adversary or where it's by the CA. The
only way to safely mitigate these issues, much like RSA-1024, is to disable
at the entire chain.

Since that's the only way for the *Browser* to be secure, it's good to
ensure that *CAs* don't engage in practices that make it difficult. That
is, instead of CA1 being SHA-1, having there be a CA2 that is SHA-256 means
that disabling SHA1 is *not* going to break the Subscriber's site.


>
> 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
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20140908/edfefaeb/attachment.html