32 bits is rather ... low.
> -----Original Message----- > From: dev-security-policy [mailto:dev-security-policy- > bounces+tim.hollebeek=digicert....@lists.mozilla.org] On Behalf Of Buschart, > Rufus via dev-security-policy > Sent: Monday, April 30, 2018 2:25 AM > To: mozilla-dev-security-policy > <mozilla-dev-security-pol...@lists.mozilla.org> > Cc: Wichmann, Markus Peter <markus.wichm...@siemens.com>; Enrico > Entschew <enr...@entschew.com>; Grotz, Florian > <florian.gr...@siemens.com>; Heusler, Juergen > <juergen.heus...@siemens.com>; Wayne Thayer <wtha...@mozilla.com> > Subject: AW: Policy 2.6 Proposal: Add prohibition on CA key generation to > policy > > ---=== 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://clicktime.symantec.com/a/1/HUkfAMaSNDzueZ8VpAI5fwA5As67iQ8caf > D > > > WBr1uThY=?d=ckuHENZYbUJhkHaGquLNZOFaRZP9Zc8e3rxXzIneBrhS9PY6Y5iu > qxaNSQ > > CO7umlrvB6qtPvWhKg1hOt- > 2VGAgBHkdp7nRO9u6gGSrCiQ5v77xypwOc0krIjNpHe3P_8 > > K4fNqBkxtFgHPPRsjnUrWo6Nfut4RREp2XdN4JmAN5a0_Cq- > KD_3YVYUsmlED3KJBAPwUX > > > iunRGjvX_UO6wuk621g6OXR1oeHDV_bXTgF86SIyOLmLgkGFvIqEapcu7fJ586Bw > XR1uCV > > 8gq0HQREMlTc_HMD1E4L5sm7g1-GWjLMQdOIJJNK88wXlBK2yuCTd_0K- > 7Qbvt8DWKSQME > > NFnvkl5pb6pw6nhSUCEndZT2W45FaXBUVA4HO_-WtnzmCGQavYymFv- > xnwBMawaicOyUGr > > FGM3wkQ5QEkKG4HuCXwzqFi- > 2XstRmiDm9CeSmhFrNoq1pFlsgL0sV8eqyVTAToo95agOr > > viwOY0FWxUtqdwtZpEaa0- > Npt_i4xVUnObY1uVKBclNwXtcDnDVHLC2A%3D%3D&u=https > > %3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://clicktime.symantec.com/a/1/HUkfAMaSNDzueZ8VpAI5fwA5As67iQ8caf > DWBr1uThY=?d=ckuHENZYbUJhkHaGquLNZOFaRZP9Zc8e3rxXzIneBrhS9PY6Y5i > uqxaNSQCO7umlrvB6qtPvWhKg1hOt- > 2VGAgBHkdp7nRO9u6gGSrCiQ5v77xypwOc0krIjNpHe3P_8K4fNqBkxtFgHPPRsj > nUrWo6Nfut4RREp2XdN4JmAN5a0_Cq- > KD_3YVYUsmlED3KJBAPwUXiunRGjvX_UO6wuk621g6OXR1oeHDV_bXTgF86SIy > OLmLgkGFvIqEapcu7fJ586BwXR1uCV8gq0HQREMlTc_HMD1E4L5sm7g1- > GWjLMQdOIJJNK88wXlBK2yuCTd_0K- > 7Qbvt8DWKSQMENFnvkl5pb6pw6nhSUCEndZT2W45FaXBUVA4HO_- > WtnzmCGQavYymFv-xnwBMawaicOyUGrFGM3wkQ5QEkKG4HuCXwzqFi- > 2XstRmiDm9CeSmhFrNoq1pFlsgL0sV8eqyVTAToo95agOrviwOY0FWxUtqdwtZp > Eaa0- > Npt_i4xVUnObY1uVKBclNwXtcDnDVHLC2A%3D%3D&u=https%3A%2F%2Flists. > mozilla.org%2Flistinfo%2Fdev-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
