My only objection is that this will cause key generation to shift to partners and affiliates, who will almost certainly do an even worse job.
If you want to ban key generation by anyone but the end entity, ban key generation by anyone but the end entity. -Tim > -----Original Message----- > From: dev-security-policy [mailto:dev-security-policy- > bounces+tim.hollebeek=digicert....@lists.mozilla.org] On Behalf Of Wayne > Thayer via dev-security-policy > Sent: Tuesday, May 15, 2018 4:10 PM > To: Dimitris Zacharopoulos <ji...@it.auth.gr> > Cc: 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) > > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
