[cabfpub] Mozilla SHA-1 further restrictions

Andrew Ayer andrew at sslmate.com
Thu Nov 17 16:44:14 UTC 2016


On Thu, 17 Nov 2016 16:18:17 +0000
Gervase Markham via Public <public at cabforum.org> wrote:

> 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:
> 
> * the cert has a Basic Constraints extension with a value of false in
>   the cA component;
> 
> * Doing so is necessary for a documented compatibility reason;
> 
> * The CA takes care the all of the signed data is either static,
>   defined by the CA, or of a known and expected form.

I think this change takes us in the wrong direction.  It would forbid
pre-generation of static OCSP responses signed directly by a cA:true
certificate, which is safe, while allowing good OCSP responses to be
forged for revoked certificates.

If CAs really have to keep signing attacker-controlled non-certificate
data with SHA-1, perhaps we could have a gradual phase-in of this
requirement. For instance:

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 doing so is necessary for a documented compatibility reason
and either of the following is true:

 * The entire signed data is static or defined by the CA.

 * The date of signing is prior to January 1, 2019, the cert has a
   Basic Constraints extension with a value of false in the cA component,
   and the signed data is of a known and expected form.

(Aside: "known and expected form" is rather vague. For instance, would
CAs know to limit the length of nonces and serial numbers in OCSP
responses if this is not spelled out explicitly?)

Regards,
Andrew



More information about the Public mailing list