[cabfpub] Mozilla SHA-1 further restrictions

[Gervase Markham]

On 17/11/16 13:05, Doug Beattie wrote:
> This section is a bit unclear in scope. Maybe we need 2 sections, one
> for rules for generating CA certificates and one for End Entity
> certificates because you go back and forth in scope.

Yes, fair.

> * The certificate is not within the scope of the Baseline
> Requirements; [DB] - the EE or the CA?

EE.

> * The issuing CA and the certificate itself both have a critical EKU
> extension with a single key purpose, which is not id-kp-serverAuth or
> anyExtendedKeyUsage; [DB] I think we should allow multiple EKUs so we
> can support SMIME & Client auth (for example) in one CA.

I would be open to suggestions for permitted pairs, but the more EKUs an
intermediate has, the greater the usefulness of a SHA-1 collision under
it. So I want to keep that to a minimum.

> * The certificate has at least 64 bits of entropy from a CSPRNG in
> the serial number. [DB] CA and End Entity?

No, EE. My current view is that CAs can be trusted not to issue SHA-1
intermediates which are designed for a collision.

> CAs may only sign SHA-1 hashes over non-certificate data (e.g. OCSP
> responses, CRLs) using certs which chain up to roots in Mozilla's
> program if all of the following are true: [DB] What do you mean by
> "CA"?  Do you mean a CA certificate, one that has Basic constraints
> set to CA?

I mean a Certificate Authority, the organization. Note the sentence goes
on to say "using certs which".

> * All of the signed data is static, or defined by the CA and not
> another party. [DB] The rules should be different if it's the CA
> certificate or a technically constrained non-CA cert.  For example,
> OCSP signing certs with EKU constrained to that should be allowed to
> sign OCSP messages with nonces, but a CA should not.

Presumably you are counting the nonce as data not defined by the CA?

Given that a nonce is a fixed short-ish length, do you think it could be
used to engineer a collision?

> compatibility testing with EKUs in intermediates. [DB] Is this going
> to be a retroactive requirement such that existing CAs need to be
> re-created?

If existing intermediate keys which are part of certificates which don't
fit the profile want to continue to sign EE certs with SHA-1, the keys
will need re-inserting into new compliant certificates. That should be
clear from the way it's worded - if you want to continue to issue SHA-1,
your intermediates have to be X, Y and Z.

Gerv