[cabfpub] Mozilla SHA-1 further restrictions

Erwann Abalea Erwann.Abalea at docusign.com
Thu Nov 17 18:41:01 UTC 2016


> Le 17 nov. 2016 à 18:00, Gervase Markham <gerv at mozilla.org> a écrit :
> 
> On 17/11/16 16:31, Erwann Abalea wrote:
>> This results in the situation where a {BC:cA=True,
>> keyUsage=keyCertSign+keyCrlSign} certificate would be denied the
>> right to sign a CRL. Same reasoning with an OCSP response (signed by
>> the CA itself).
> 
> Well, OK. I think what I'm trying to achieve here (not allowing signing
> of attacker-controlled data) is clear; can someone tell me how to write
> that?
> 
>>> Let's say someone signs an email cert from an intermediate without 
>>> pathlen:0. If there's a collision, that signature can be passed to
>>> an intermediate cert which can sign email certs for any email
>>> address. But if it has a pathlen, they can only create an EE cert.
>> 
>> An attacker could collide and generate a self-issued CA certificate,
>> again with BC:pathLenConstraint=0 (this is valid).
> 
> Er, I don't understand what you are saying here. If it's self-signed,
> no-one would trust it. But it can't chain, because the intermediate
> about has pathlen=0.


It would be self-issued, not self-signed.

Standard and valid chain:
RootCA (subject: "C=UT, O=PerfectCA, CN=Root")
  -> OnlineCA (subject: "C=UT, O=PerfectCA, CN=Online", pathLen=0)
    -> EE

Invalid chain:
RootCA (subject: "C=UT, O=PerfectCA, CN=Root")
  -> OnlineCA (subject: "C=UT, O=PerfectCA, CN=Online", pathLen=0)
    -> OnlineCA2 (subject: "C=UT, O=PerfectCA, CN=Online2", pathLen=0)
      -> EE

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).


Cordialement,
Erwann Abalea



More information about the Public mailing list