Wayne: I agree with your latest proposal.
> -----Original Message----- > From: dev-security-policy [mailto:dev-security-policy- > bounces+doug.beattie=globalsign....@lists.mozilla.org] On Behalf Of Wayne > Thayer via dev-security-policy > Sent: Monday, April 9, 2018 7:10 PM > To: mozilla-dev-security-policy > <mozilla-dev-security-pol...@lists.mozilla.org> > Subject: Re: Policy 2.6 Proposal: Add prohibition on CA key generation to > policy > > Getting back to the earlier question about email certificates, I am now of the > opinion that we should limit the scope of this policy update to TLS > certificates. > The current language for email certificates isn't clear and any attempt to > fix it > requires us to answer the bigger question of "under what circumstances is CA > key generation acceptable?" > > My updated proposal is to add 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 certificates with the Extended Key Usage extension present and > > set to id-kp-emailProtection. > > > > > > 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. > > > Once again, I would appreciate your comments on this proposal. > > - Wayne > > > On Mon, Apr 9, 2018 at 3:54 PM, Wayne Thayer <wtha...@mozilla.com> > wrote: > > > On Thu, Apr 5, 2018 at 12:29 PM, Jakob Bohm via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > > >> On 05/04/2018 18:55, Wayne Thayer wrote: > >> > >>> On Thu, Apr 5, 2018 at 3:15 AM, Dimitris Zacharopoulos > >>> <ji...@it.auth.gr > >>> > > >>> wrote: > >>> > >>> My proposal is "CAs MUST NOT distribute or transfer private keys and > >>>> associated certificates in PKCS#12 form through insecure physical > >>>> or electronic channels " and remove the rest. > >>>> > >>>> +1 - I support this proposal. > >>>> > >>> > >> But that removes the explicit exception for methods such as the > >> following *example* protocol (securing such a protocol is the job and > >> expertise of the affected CAs). > >> > >> This is a valid point, so perhaps we should stick with the original > > language regarding distribution of PKCS12 files on physical storage devices. > > > > 1. Set the notBefore data in the new certificate several days or weeks > >> into the future. > >> > >> 2. Securely store the PKCS#12 or other private key format on a USB > >> stick, USB token or smartcard. > >> > >> 3. Place that device in a physically sealed envelope or package. > >> > >> 4. Send it through regular postal mail (an insecure physical channel). > >> > >> 5. Upon receiving the envelope/package, the subscriber must verify that > >> the seal is unbroken and acknowledge that, through a secure electronic > >> channel. The procedure may/should include additional steps to verify > >> that the sealed envelope/package is the same one sent. > >> > >> 6. If this is not done before the certificate's notBefore date, the > >> certificate is preemptively revoked due to private key compromise and > >> issuance is retried with a new key. > >> > >> > >> Enjoy > >> > >> Jakob > >> > >> > > > _______________________________________________ > 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
