On Tue, 8 Nov 2016 11:17:29 +0000 Gervase Markham <g...@mozilla.org> wrote:
> On 07/11/16 17:09, Nick Lamb wrote: > > On Monday, 7 November 2016 13:53:31 UTC, Gervase Markham wrote: > >> You mean EKU-constrained (e.g. to email, or OCSP only)? > > > > I was thinking also of a pathlen constraint. > > Aha. So what would this look like? Something like this? > > > CAs may only issue SHA-1 end-entity certs chaining up to roots in > Mozilla's program if the following is true: > > * The certificate is not within the scope of the Baseline > Requirements; > * 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; > * The issuing CA has a pathlen:0 constraint > * The certificate has at least 64 bits of entropy from a CSPRNG in the > serial number > > > I guess it doesn't cover signing other things like OCSP responses. > Perhaps we could add: > > > * CAs may sign other data (such as OCSP responses) with SHA-1 for > compatibility reasons, as long as all of the signed data is static, or > defined by the CA and not by a customer. > > > Is this heading in the right direction? Too weak, too strong? Hi Gerv, Thanks for kicking this off. I think this is heading in the right direction. The rule about other data could be clarified. We want to make sure there is no room for misinterpretation. Here's some suggested text: Keys used by CAs chaining up to a root in Mozilla's program may only sign non-certificate data (e.g. OCSP responses, CRLs) with SHA-1 if all the following is true: * Doing so is necessary for a documented compatibility reason; * All of the signed data is static, or defined by the CA and not another party Regards, Andrew _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
