[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