I don't think that is true. Remember for OV/IV/EV certificates, the Subscriber is the natural person or Legal Entity identified in the certificate Subject. If the Subscriber is using the certificate on a CDN, it is probably better to have the CDN generate the key rather than the Subscriber. The key is never being passed around, in PKCS#12 format or otherwise, even though the Subscriber isn't generating the key.
On Tue, May 15, 2018 at 9:17 PM, Tim Hollebeek via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > 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 > > _______________________________________________ > 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
