The current policy seems inconsistent on the trust placed in passwords to protect PKCS#12 files. On one hand, it forbids transmission via insecure electronic channels regardless of password protection. But it goes on to permit transmission of PKCS#12 files on a storage device as long as a "sufficiently strong" password is delivered via a different means. If we trust PKCS#12 encryption with a strong password (it's not clear that we should [1]), then the policy could be:
PKCS#12 files SHALL have a password containing at least 64 bits of output from a CSPRNG, and the password SHALL be transferred using a different channel than the PKCS#12 file. This eliminates the need for separate rules pertaining to physical storage devices. Is there a good reason to allow transmission of PKCS#12 files with weak/no passwords over "secure" channels? [1] http://unmitigatedrisk.com/?p=543 On Mon, Apr 30, 2018 at 10:46 AM, Tim Hollebeek <tim.holleb...@digicert.com> wrote: > 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. > > That is copied from the current policy, and while it's confusing I believe it just means 'tamper evident'. -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
