Hey Wayne, This should be a really easy thing, but it's not.
First comments on this: "MUST be encrypted and signed; or, MUST have a password that..." - Isn't the password the key used for encryption? I'm not sure if the "or" makes sense since in both cases the password is the key for encryption - In general, I don't think PKCS#12 files are signed, so I'd leave that out, a signature isn't necessary. I could be wrong... I'd still like to see a modification on the requirement: "password MUST be transferred using a different channel than the PKCS#12 file". A user should be able to download the P12 and password via HTTP. Can we add an exception for that? Doug > -----Original Message----- > From: dev-security-policy [mailto:dev-security-policy- > bounces+doug.beattie=globalsign....@lists.mozilla.org] On Behalf Of Wayne > Thayer via dev-security-policy > Sent: Friday, May 4, 2018 2:58 PM > To: mozilla-dev-security-policy > <mozilla-dev-security-pol...@lists.mozilla.org> > Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key > generation to policy) > > The optimist in me thinks we might be getting close to resolving this issue > (the > last one remaining for the 2.6 policy update). Here is another proposal that > attempts to account for most of the input we've received: > > Add the following to section 5.2 (Forbidden and Required Practices): > > CAs MUST NOT generate the key pairs for end-entity certificates that have > > an EKU extension containing the KeyPurposeIds id-kp-serverAuth or > > anyExtendedKeyUsage. > > > > PKCS#12 files must employ an encryption algorithm that is sufficiently > > strong to protect the key pair for its useful life based on current > > guidelines published by a recognized standards body. PKCS#12 files > > MUST be encrypted and signed; or, MUST have a password that exhibits > > at least 112 bits of entropy, and the password MUST be transferred > > using a different channel than the PKCS#12 file. > > > > This isn't perfect. I would appreciate your comments if you have significant > concerns with this proposed policy. > > - Wayne > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
