I'm coming to the conclusion that this discussion is about "security theater"[1]. As long as we allow CAs to generate S/MIME key pairs, there are gaping holes in the PKCS#12 requirements, the most obvious being that a CA can just transfer the private key to the user in pem format! Are there any objections to dropping the PKCS#12 requirements altogether and just forbidding key generation for TLS certificates as follows?
CAs MUST NOT generate the key pairs for end-entity certificates that have an EKU extension containing the KeyPurposeIds id-kp-serverAuth or anyExtendedKeyUsage. - Wayne [1] https://en.wikipedia.org/wiki/Security_theater On Tue, May 15, 2018 at 10:23 AM Dimitris Zacharopoulos <ji...@it.auth.gr> wrote: > > > On 15/5/2018 6:51 μμ, Wayne Thayer via dev-security-policy wrote: > > Did you consider any changes based on Jakob’s comments? If the PKCS#12 is > distributed via secure channels, how strong does the password need to be? > > > > > > I think this depends on our threat model, which to be fair is not something > we've defined. If we're only concerned with protecting the delivery of the > PKCS#12 file to the user, then this makes sense. If we're also concerned > with protection of the file while in possession of the user, then a strong > password makes sense regardless of the delivery mechanism. > > > I think once the key material is securely delivered to the user, it is no > longer under the CA's control and we shouldn't assume that it is. The user > might change the passphrase of the PKCS#12 file to whatever, or store the > private key without any encryption. > > > Dimitris. > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
