Hi Wayne, I’m OK with this as long as this permits the password (fully or partially generated by the CA) and PKCS#12 file to be picked up by a user over HTTPS (a single channel).
Doug From: Wayne Thayer [mailto:wtha...@mozilla.com] Sent: Wednesday, May 9, 2018 11:43 PM To: Doug Beattie <doug.beat...@globalsign.com> Cc: mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: FW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy) I think we have settled on the following resolution to this issue: 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 key and 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. Unless there is further discussion, I will include this language in the final version of the policy. - Wayne _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
