Once again, CSPRNGs are not overkill. They are widely available in virtually every programming language in existence these days. I have never understood why there is so much pushback against something that often appears near the top of many top ten lists about basic principles for secure coding.
Also, while I'm responding, and since it got copied into your proposal, 32 bits is still way too small. "irrecoverable physical damage" ? You want to go beyond tamper evident, and even tamper responsive, and require self-destruction on tamper?? I personally think we probably want to get out of the area of writing requirements about physical distribution. They're VERY hard to get right. -Tim > -----Original Message----- > From: dev-security-policy [mailto:dev-security-policy- > bounces+tim.hollebeek=digicert....@lists.mozilla.org] On Behalf Of Doug > Beattie via dev-security-policy > Sent: Monday, April 30, 2018 1:06 PM > To: Buschart, Rufus <rufus.busch...@siemens.com>; 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: RE: Policy 2.6 Proposal: Add prohibition on CA key generation to > policy > > > 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
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
