I agree we need to tighten up Wayne's initial proposal a little. ----- Initial proposal (Wayne):
CAs MUST NOT distribute or transfer certificates in PKCS#12 form through insecure electronic channels. The PKCS#12 file must have a sufficiently secure password, and the password must not be transferred together with the file. 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) ----- Proposal #1 (Rufus): CAs SHOULD NOT distribute or transfer certificates in PKCS#12 form through insecure electronic channels. If the CA chooses to do so, the PKCS#12 file SHALL have a password containing at least 32 bit of output from a CSPRNG, and the password SHALL be transferred using a different channel as the PKCS#12 file. ---- Proposal #2 (Doug) If the PKCS#12 is distributed thought an insecure electronic channel then the PKCS#12 file SHALL have a password containing at least 32 bit of entropy and the PKCS#12 file and the password SHALL be transferred using a different channels. If the PKCS#12 is distributed through a secure electronic channel, then... <If secure channels are used are there are any requirements on the strength of the password or the use of multiple distribution channels? Can you send both the P12 and password in a secure S/MIME email or a user can view/download both in the same session from a website? We should be clear.> If a PKCS#12 file is distributed via a non-secure physical data storage device <need definition>, then a) the storage must be packaged in a way that the opening of the package causes irrecoverable physical damage. (e.g. a security seal), or b) the PKCS#12 must have a password of at least 32 bits of entropy and the password must be sent via separate channel. ---- Comments: 1) The discussions to date have not addressed the use of secure channels on the quality of the password, nor on the use of multiple channels. What is the intent? We should specify that so it's clear. 2) I think the use of CSPRNG is overkill for this application. Can we leave this at a certain entropy level? 3) The tamper requirement would only seem applicable if the P12 wasn't protected well (via strong P12 password on USB storage or via "good" PIN on a suitably secure crypto token). > -----Original Message----- > > I would like to suggest to rephrase the central sentence a little bit: > > Original: > > CAs MUST NOT distribute or transfer certificates in PKCS#12 form through > insecure electronic channels. The PKCS#12 file must have a sufficiently > secure > password, and the password must not be transferred together with the file. > > Proposal: > > CAs SHOULD NOT distribute or transfer certificates in PKCS#12 form through > insecure electronic channels. If the CA chooses to do so, the PKCS#12 file > SHALL have a password containing at least 32 bit of output from a CSPRNG, > and the password SHALL be transferred using a different channel as the > PKCS#12 file. > > My proposal would allow a CA to centrally generate a P12 file, send it to the > Subject by unencrypted email and send the P12 pin as a SMS or Threema > message. This is an important use case if you want to have email encryption on > a mobile device that is not managed by a mobile device management system. > Additionally I made the wording a little bit more rfc2119-ish and made clear, > what defines a 'sufficiently secure password' as the original wording lets a > lot > of room for 'interpretation'. > > What do you think? > > /Rufus > > > Siemens AG > Information Technology > Human Resources > PKI / Trustcenter > GS IT HR 7 4 > Hugo-Junkers-Str. 9 > 90411 Nuernberg, Germany > Tel.: +49 1522 2894134 > mailto:rufus.busch...@siemens.com > www.twitter.com/siemens > > www.siemens.com/ingenuityforlife > > Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann > Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive > Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, > Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; > Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; > WEEE-Reg.-No. DE 23691322 > > > -----Ursprüngliche Nachricht----- > > Von: dev-security-policy > > [mailto:dev-security-policy-bounces+rufus.buschart=siemens.com@lists.m > > ozilla.org] Im Auftrag von Wayne Thayer via dev-security-policy > > Gesendet: Freitag, 27. April 2018 19:30 > > An: Enrico Entschew > > Cc: mozilla-dev-security-policy > > Betreff: Re: Policy 2.6 Proposal: Add prohibition on CA key generation > > to policy > > > > On Fri, Apr 27, 2018 at 6:40 AM, Enrico Entschew via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > > > I suggest to make the requirement „* The PKCS#12 file must have a > > > sufficiently secure password, and the password must be transferred > > > via a separate channel than the PKCS#12 file.” binding for both > > > transfer methods and not be limited to physical data storage. > > > Otherwise I agree with this proposal. > > > > > > Enrico > > > > > > That seems like a good and reasonable change, resulting in the > > > following > > policy: > > > > CAs MUST NOT generate the key pairs for end-entity certificates that > > have EKU extension containing the KeyPurposeIds id-kp- serverAuth or > anyExtendedKeyUsage. > > > > CAs MUST NOT distribute or transfer certificates in PKCS#12 form > > through insecure electronic channels. The PKCS#12 file must have a > > sufficiently secure password, and the password must not be transferred > > together with the file. 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) > > > > Unless other comments are made, I'll consider this to be the conclusion of > discussion on this topic. > > > > Wayne > > _______________________________________________ > > 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
