[cabfpub] Mozilla SHA-1 further restrictions

[Doug Beattie]

Gerv,

While I agree that technically constraining CAs not intended to issue BR certificates is a good goal, it gets complicated, and limiting those CAs to a single EKU is essentially impossible.  For one, it's very common to have Client auth and SMIME in one cert.

Why is it so hard?  Well, here is the list of EKUs that we like to support, and more are identified on a regular basis:

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


* Do you propose CAs set up 5-10 CAs to support client certificates for each customer with a dedicated CA?
* Do you propose that CAs create new CA certificates every time a new EKU needs to be supported in an end entity certificate?

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

Doug


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

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

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

Or if someone signs an email cert from an intermediate without an EKU, if there's a collision that sig can be transferred to any other type of cert or signed object. But if there's an EKU, it can only be transferred to the type of object the original signed thing was, thereby reducing the value of the attack.

Gerv