[cabfpub] Mozilla SHA-1 further restrictions

[Erwann Abalea]

Bonjour,


> Le 17 nov. 2016 à 16:24, Gervase Markham via Public <public at cabforum.org> a écrit :
> 
> On 17/11/16 14:54, Doug Beattie wrote:
>> [DB] Yes, I think it does.  You might want to define what "cert data"
>> is so we what "non-cert data" is.  I'm assuming Cert data consists of
>> certificates, CRLs and OCSP responses, nothing else.
> 
> My definition was that cert data is, er, certs, and non-cert data is
> everything else, including CRLs and OCSP. Does that make the following
> problematic?
> 
> "If you want to sign something that's not a certificate, you have to do
> the signing with a cert that has a Basic Constraints extension with a
> value of false in the cA component. »

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

> 
>> Yes, sorry, I mis-spoke. What I think I mean is that existing
>> intermediates certs that fit the profile can continue to be used, but
>> you have to stop using those which don't, and mint new intermediates
>> with new keys to replace them. In other words, rotate your
>> intermediates. You can't reuse the same keys because, you are right,
>> that doesn't help, as the SHA-1 signatures could still be transferred
>> and used with the old intermediate which has the same key. If we do
>> it this way, you don't have to revoke the old ones, you just have to
>> stop signing SHA-1 things with them. So existing systems continue to
>> work.
>> 
>> [DB] What's driving this change now, especially given that SHA-1 SSL
>> certificates won’t be trusted by the time this requirement is
>> enforced?  This is going to be a lot of work for CAs to re-cut all of
>> the CAs (shared and dedicated ones for customers).  Even if someone
>> could get an SSL certificate from one of these CAs, it would be of
>> minimal use.  Specifying this requirement for new CAs is fine.
> 
> Firstly, it's not just about SSL - Mozilla's policy also covers S/MIME.
> 
> 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).

Cordialement,
Erwann Abalea