[cabfpub] Mozilla SHA-1 further restrictions

Erwann Abalea Erwann.Abalea at docusign.com
Fri Nov 18 09:19:21 MST 2016


Le 18 nov. 2016 à 14:56, Gervase Markham <gerv at mozilla.org<mailto:gerv at mozilla.org>> a écrit :

On 17/11/16 18:41, Erwann Abalea wrote:
Another valid chain:
RootCA (subject: "C=UT, O=PerfectCA, CN=Root")
 -> OnlineCA (subject: "C=UT, O=PerfectCA, CN=Online", pathLen=0)
   -> OnlineCA (subject: "C=UT, O=PerfectCA, CN=Online", pathLen=0) <= this is the self-issued cert, same name
     -> EE

Having a pathLen=0 doesn’t forbid you from creating a CA
certificate, it only forbids you from creating a CA certificate
for a different CA. This is defined in X.509 and repeated in RFC5280.
This behaviour is supported by OpenSSL, probably by Microsoft
(haven’t checked), I guess by Mozilla libPKIX but not Mozilla::pkix
(just quickly read the source).

Well, %$£&*.

So an attacker can effectively leverage a SHA-1 collision into a cert
which is equivalent to the issuing intermediate but for which they
control the private key?

Yes.

RFC5280 section 4.2.1.9 Basic Constraints:
…
   The pathLenConstraint field is meaningful only if the cA boolean is
   asserted and the key usage extension, if present, asserts the
   keyCertSign bit (Section 4.2.1.3).  In this case, it gives the
   maximum number of non-self-issued intermediate certificates that may
   follow this certificate in a valid certification path.


And this is taken into account in section 6.1 presenting the validation algorithm.


Cordialement,
Erwann Abalea

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20161118/e800d1cb/attachment.html>


More information about the Public mailing list