> -----Original Message----- > From: dev-security-policy [mailto:dev-security-policy- > [email protected]] On Behalf Of Wayne > Thayer via dev-security-policy > Sent: Wednesday, April 4, 2018 5:26 PM > To: mozilla-dev-security-policy > <[email protected]> > Subject: Policy 2.6 Proposal: Add prohibition on CA key generation to policy > > I propose adding the following paragraphs to section 5.3 “Forbidden and > Required Practices”: > > CAs MUST not generate the key pairs for end-entity certificates, except for > > email encryption certificates meeting the following criteria: > > 1. The Extended Key Usage extension is present and set to > > id-kp-emailProtection; and, 2. The Key Usage extension is present and > > does not include either digitalSignature or nonRepudiation.
I don’t think you should include #2 because it's a common practice to issue one certificate for Secure Mail that is used to both sign and encrypt, and this would preclude CA key generation for those types of certificates. It's a fine line between what enterprises do and what they contract CAs to do. Based on this requirement, Enterprise customers can generate keys for any type of certificate but CAs are being specifically called out to be excluded from this. While CAs strive to provide a complete managed solution for their customers, this requirement prevents that from happening. Take for example a CA that has an appliance located in the enterprise. If that appliance generates keys, is that the "CA" generating the keys? It gets muddy. I'd prefer that CAs be permitted to perform key generation for any certificate with an EKU of id-kp-emailProtection with key usage of keyEncipherment or dataEncipherment, but perhaps with an acknowledgement from the enterprise or end users that they acknowledge the fact the CA may have access to their private keys. > > > > CAs MUST not distribute or transfer certificates in PKCS#12 form through > > insecure electronic channels. If a PKCS#12 file is distributed via a > > physical data storage device, then: > > * The storage must be packaged in a way that the opening of the > > package causes irrecoverable physical damage. (e.g. a security seal) > > * The PKCS#12 file must have a sufficiently secure password, and the > > password must not be transferred together with the storage. > > > > I would appreciate everyone's input on this topic. > > This is: https://github.com/mozilla/pkipolicy/issues/107 > > [1] https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices > [2] > https://groups.google.com/d/msg/mozilla.dev.security.policy/UnPOf5WIpXM/S > bmSD5eCAgAJ > [3] > https://groups.google.com/d/msg/mozilla.dev.security.policy/MRd8gDwGGA4/ > AC4xgZ9CBgAJ > > ------- > > This is a proposed update to Mozilla's root store policy for version 2.6. > Please > keep discussion in this group rather than on GitHub. Silence is consent. > > Policy 2.5 (current version): > https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
