We should allow someone to obtain/view the P12 password and to download the P12 over an authenticated web site (managed portal), and that seems to be precluded by the definition below.
Doug From: Tim Hollebeek [mailto:tim.holleb...@digicert.com] Sent: Monday, April 30, 2018 3:05 PM To: Wayne Thayer <wtha...@mozilla.com> Cc: Doug Beattie <doug.beat...@globalsign.com>; Buschart, Rufus <rufus.busch...@siemens.com>; mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org>; Wichmann, Markus Peter <markus.wichm...@siemens.com>; Enrico Entschew <enr...@entschew.com>; Grotz, Florian <florian.gr...@siemens.com>; Heusler, Juergen <juergen.heus...@siemens.com> Subject: RE: Policy 2.6 Proposal: Add prohibition on CA key generation to policy OOB passwords are generally tough to integrate into automation, and if the channel really is “secure” then they might not be buying you anything, depending where the “secure” channel starts and ends and how it is authenticated. That might not be a GOOD reason to allow it, but it is the one reason that comes to mind. Taking the other side, I’d argue that it’s unlikely that the “secure” channel stretches unbroken from the site of key generation to the key loading/usage site. And it’s possible that “secure” is being used incorrectly, and the channel is encrypted but not authenticated. In that case, having a strong password does help for at least a portion of the transmission. -Tim From: Wayne Thayer [mailto:wtha...@mozilla.com] Sent: Monday, April 30, 2018 2:25 PM To: Tim Hollebeek <tim.holleb...@digicert.com> Cc: Doug Beattie <doug.beat...@globalsign.com>; Buschart, Rufus <rufus.busch...@siemens.com>; mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org>; Wichmann, Markus Peter <markus.wichm...@siemens.com>; Enrico Entschew <enr...@entschew.com>; Grotz, Florian <florian.gr...@siemens.com>; Heusler, Juergen <juergen.heus...@siemens.com> Subject: Re: Policy 2.6 Proposal: Add prohibition on CA key generation to policy 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 <mailto: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:mailto:dev-security-policy- > bounces+tim.hollebeek=mailto:digicert....@lists.mozilla.org] On Behalf Of Doug > Beattie via dev-security-policy > Sent: Monday, April 30, 2018 1:06 PM > To: Buschart, Rufus <mailto:rufus.busch...@siemens.com>; mozilla-dev-security- > policy <mailto:mozilla-dev-security-pol...@lists.mozilla.org> > Cc: Wichmann, Markus Peter <mailto:markus.wichm...@siemens.com>; Enrico > Entschew <mailto:enr...@entschew.com>; Grotz, Florian > <mailto:florian.gr...@siemens.com>; Heusler, Juergen > <mailto:juergen.heus...@siemens.com>; Wayne Thayer > <mailto: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:mailto:rufus.busch...@siemens.com > > http://www.twitter.com/siemens > > > > http://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:mailto:dev-security-policy-bounces%2Brufus.buschart=siemens.com@lists > > > .m http://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 < > > mailto: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
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
