---=== Intern ===--- Hello! 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
