[cabfpub] Mozilla SHA-1 further restrictions

[Doug Beattie]

Gerv,

Are you specifically concerned about the id-kp-emailProtection and what needs to be combined with that, or is the issue what's the total set of EKUs that might be needed?  In other words, do you care less if a CA has all of the below except id-kp-emailProtection?

id-kp-clientAuth 1.3.6.1.5.5.7.3.2
id-kp-emailProtection 1.3.6.1.5.5.7.3.4 
Smart Card Logon     1.3.6.1.4.1.311.20.2.2
id-kp-ipsecIKE	1.3.6.1.5.5.7.3.17
Key Archival	 1.3.6.1.4.1.311.21.5
Key Recovery Agent	1.3.6.1.4.1.311.21.6
Encrypting File System (EFS) 1.3.6.1.4.1.311.10.3.4
EFS Recovery	1.3.6.1.4.1.311.10.3.4.1
Bitlocker Drive Encryption	1.3.6.1.4.1.311.67.1.1
Bitlocker Data Recovery Agent	 1.3.6.1.4.1.311.67.1.2


By the way, we have the same challenge with our SSL CAs - there's a set of EKUs we'd like to include in SSL certs to support Domain Controllers and VPN servers.

-----Original Message-----
From: Gervase Markham [mailto:gerv at mozilla.org] 
Sent: Friday, November 18, 2016 9:03 AM
To: Doug Beattie <doug.beattie at globalsign.com>
Cc: CA/Browser Forum Public Discussion List <public at cabforum.org>
Subject: Re: [cabfpub] Mozilla SHA-1 further restrictions

On 18/11/16 13:48, Doug Beattie wrote:
> * Do you propose that CAs
> create new CA certificates every time a new EKU needs to be supported 
> in an end entity certificate?

If we are going to avoid having SHA-1-issuing intermediates out there which can also issue server certs, then they are all going to need to be EKU-constrained, and so this particular bullet is going to be necessary.

> Please reconsider the EKU requirement in CA certificates (SHA-1 and 
> SHA-256).  It's too bad we can't say: AnyEKU except id-kp-serverAuth 
> or id-kp-codeSigning

I can see the issue you are raising, but I wonder if there is a middle ground between the current position and "anything in any combination as long as no serverAuth". Particularly as, if Erwann is right, the
pathlen=0 constraint can be bypassed. I'm particularly concerned about email, that being the other thing Mozilla's root store now cares about.

What EKUs are commonly combined in an EE cert with id-kp-emailProtection, other than id-kp-clientAuth?

Gerv