Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)
On Fri, Jun 8, 2018 at 2:32 PM Buschart, Rufus wrote: > Did we somehow came to a conclusion / agreed wording here? I'm not sure if > I missed something, but the last email I've received in regards to this > issue is from mid of May and the last change in > https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md > dates to beginning of March. I don't want to make artificial pressure here > but want to be sure I don't miss something important. > > I went ahead with my most recent proposal from 15-March and removed all of the PKCS#12 language from the proposal: https://github.com/mozilla/pkipolicy/commit/c56e0fed3d9ada3bba2f466b3ba638dc652b913b These changes are in the 2.6 branch on GitHub. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
AW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)
Did we somehow came to a conclusion / agreed wording here? I'm not sure if I missed something, but the last email I've received in regards to this issue is from mid of May and the last change in https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md dates to beginning of March. I don't want to make artificial pressure here but want to be sure I don't miss something important. With best regards, Rufus Buschart 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 Tim Hollebeek via dev-security-policy > Gesendet: Mittwoch, 16. Mai 2018 08:23 > An: Wayne Thayer; mozilla-dev-security-policy > Betreff: RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on > CA key generation to policy) > > When we debated it last, my predictions were hypothetical. > > > > I wish they had remained hypothetical. > > > > -Tim > > > > From: Wayne Thayer [mailto:wtha...@mozilla.com] > Sent: Wednesday, May 16, 2018 12:33 AM > To: Tim Hollebeek ; > mozilla-dev-security-policy > > Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on > CA key generation to policy) > > > > On Tue, May 15, 2018 at 9:17 PM Tim Hollebeek <mailto:tim.holleb...@digicert.com> > wrote: > > My only objection is that this will cause key generation to shift to > partners and affiliates, who will almost certainly do an even worse job. > > > > > This is already a Mozilla requirement [1] - we're just moving it into the > policy document. > > > > > If you want to ban key generation by anyone but the end entity, ban key > generation by anyone but the end entity. > > > > > We've already debated this [2] and didn't come to that conclusion. > > > > > -Tim > > > > [1] > https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Distrib > uting_Generated_Private_Keys_in_PKCS.2312_Files > > [2] > https://groups.google.com/d/msg/mozilla.dev.security.policy/MRd8gDwGGA > 4/AC4xgZ9CBgAJ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)
When we debated it last, my predictions were hypothetical. I wish they had remained hypothetical. -Tim From: Wayne Thayer [mailto:wtha...@mozilla.com] Sent: Wednesday, May 16, 2018 12:33 AM To: Tim Hollebeek ; mozilla-dev-security-policy Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy) On Tue, May 15, 2018 at 9:17 PM Tim Hollebeek mailto:tim.holleb...@digicert.com> > wrote: My only objection is that this will cause key generation to shift to partners and affiliates, who will almost certainly do an even worse job. > This is already a Mozilla requirement [1] - we're just moving it into the policy document. > If you want to ban key generation by anyone but the end entity, ban key generation by anyone but the end entity. > We've already debated this [2] and didn't come to that conclusion. > -Tim [1] https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Distributing_Generated_Private_Keys_in_PKCS.2312_Files [2] https://groups.google.com/d/msg/mozilla.dev.security.policy/MRd8gDwGGA4/AC4xgZ9CBgAJ 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
Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)
I don't think that is true. Remember for OV/IV/EV certificates, the Subscriber is the natural person or Legal Entity identified in the certificate Subject. If the Subscriber is using the certificate on a CDN, it is probably better to have the CDN generate the key rather than the Subscriber. The key is never being passed around, in PKCS#12 format or otherwise, even though the Subscriber isn't generating the key. On Tue, May 15, 2018 at 9:17 PM, Tim Hollebeek via dev-security-policy wrote: > My only objection is that this will cause key generation to shift to partners > and > affiliates, who will almost certainly do an even worse job. > > If you want to ban key generation by anyone but the end entity, ban key > generation by anyone but the end entity. > > -Tim > >> -Original Message- >> From: dev-security-policy [mailto:dev-security-policy- >> bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Wayne >> Thayer via dev-security-policy >> Sent: Tuesday, May 15, 2018 4:10 PM >> To: Dimitris Zacharopoulos >> Cc: mozilla-dev-security-policy >> >> Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key >> generation to policy) >> >> I'm coming to the conclusion that this discussion is about "security >> theater"[1]. >> As long as we allow CAs to generate S/MIME key pairs, there are gaping holes >> in the PKCS#12 requirements, the most obvious being that a CA can just >> transfer the private key to the user in pem format! Are there any objections >> to >> dropping the PKCS#12 requirements altogether and just forbidding key >> generation for TLS certificates as follows? >> >> CAs MUST NOT generate the key pairs for end-entity certificates that have an >> EKU extension containing the KeyPurposeIds id-kp-serverAuth or >> anyExtendedKeyUsage. >> >> - Wayne >> >> [1] https://en.wikipedia.org/wiki/Security_theater >> >> On Tue, May 15, 2018 at 10:23 AM Dimitris Zacharopoulos >> wrote: >> >> > >> > >> > On 15/5/2018 6:51 μμ, Wayne Thayer via dev-security-policy wrote: >> > >> > Did you consider any changes based on Jakob’s comments? If the >> > PKCS#12 is distributed via secure channels, how strong does the password >> need to be? >> > >> > >> > >> > >> > >> > I think this depends on our threat model, which to be fair is not >> > something we've defined. If we're only concerned with protecting the >> > delivery of the >> > PKCS#12 file to the user, then this makes sense. If we're also >> > concerned with protection of the file while in possession of the user, >> > then a strong password makes sense regardless of the delivery mechanism. >> > >> > >> > I think once the key material is securely delivered to the user, it is >> > no longer under the CA's control and we shouldn't assume that it is. >> > The user might change the passphrase of the PKCS#12 file to whatever, >> > or store the private key without any encryption. >> > >> > >> > Dimitris. >> > >> ___ >> 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
RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)
The usual ANSI/ISO rule is that if you protect a strong key with a weak key, the strong key is now weak. This is true pretty much regardless of your threat model. It is absurdly hard to express in terms of auditable requirements, though. "Your AES-128 key has 112 bits of security because you distributed it under RSA-2048" tends to blow people's minds. Unfortunately. -Tim > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Dimitris > Zacharopoulos via dev-security-policy > Sent: Tuesday, May 15, 2018 1:23 PM > To: Wayne Thayer > Cc: mozilla-dev-security-policy > > Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key > generation to policy) > > > > On 15/5/2018 6:51 μμ, Wayne Thayer via dev-security-policy wrote: > >> Did you consider any changes based on Jakob’s comments? If the > >> PKCS#12 is distributed via secure channels, how strong does the password > need to be? > >> > >> > >> > >> > > I think this depends on our threat model, which to be fair is not > > something we've defined. If we're only concerned with protecting the > > delivery of the > > PKCS#12 file to the user, then this makes sense. If we're also > > concerned with protection of the file while in possession of the user, > > then a strong password makes sense regardless of the delivery mechanism. > > I think once the key material is securely delivered to the user, it is no > longer > under the CA's control and we shouldn't assume that it is. The user might > change the passphrase of the PKCS#12 file to whatever, or store the private > key > without any encryption. > > > Dimitris. > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://clicktime.symantec.com/a/1/E- > jZIz_DR9dHNSNR0HnesMrWlGhwKrsH7HKSGn- > ocMA=?d=6ILtenW6WksqWaTs1fXNph_dHj9tTUMLmyljUltr1AJzVv0Fmccw1ccb > 5Nm0sMC99lXGaJMbnwLGFTtPqbgZZO_iGjTsU5ZKkk- > 1lM0Kna7pLUnb7f6pHvUEwkKCK2vjAxT97AzgmNhqPNrRKxL- > A918X9yZHSkSajsV9kVDi8uxyH50O_YP9kYXzQQWasQwC1gznxInF34QUQWxQu > cPWrYt90EnC-dyfRBL_7wsJul- > RnM8fIbCVSh7k3RCeRjJWPvn1ptBjBM7sJ5C6XM7ZNdfTGA08Djz7BUzrNMXGZC > uP56D3nR6S7Umx9dm3YDau_KWs5CUjUAqJnSIlaxqx0c188ksRtkrfMRxaginzSga > OzhCNAdbeikh_p5owiH7vDAsO0EhaZd- > e40yW9bpteFvmKFsYuUOywhQuFYH3464UYwuRZo6e_EIaicvNuq9hd- > PK9CmOMs64434iClih- > _z6qOAD9kYqcJ2ell4I58Z7NUyRIQfqMtobhNSjIg8e_k5byQ4k7g%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
Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)
On Tue, May 15, 2018 at 9:17 PM Tim Hollebeek wrote: > My only objection is that this will cause key generation to shift to > partners and > affiliates, who will almost certainly do an even worse job. > > > This is already a Mozilla requirement [1] - we're just moving it into the policy document. > > If you want to ban key generation by anyone but the end entity, ban key > generation by anyone but the end entity. > > > We've already debated this [2] and didn't come to that conclusion. > > -Tim > [1] https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Distributing_Generated_Private_Keys_in_PKCS.2312_Files [2] https://groups.google.com/d/msg/mozilla.dev.security.policy/MRd8gDwGGA4/AC4xgZ9CBgAJ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)
> This going to require 19 randomly generated Base64 characters and that does > not include removing common confused characters which will drive up the > length a bit more, but if this is what the Mozilla risk assessment came up > with, > then we’ll all have to comply. I hope there is a sufficiently long time for > CAs to > change their processes and APIs and to roll out updated training and > documentation to their customers (for this unplanned change). A reasonable transition period is reasonable. > 2) Trying to compute the entropy of a user generated password is nearly > impossible. According to NIST Special Publication 800-63, a good 20 character > password will have just 48 bits of entropy, and characters after that only > add 1 > bite of entropy each. User stink at generating Entropy (right Tim?) Yes, users struggle to generate a single bit of entropy per character. This is why users should not generate keys or passwords. An encoded CSPRNG can hit 5-6 bits of entropy per character, so 20 is a pretty good number for password lengths. Copy/paste solves most of the usability issues. There are some subtleties that require some care, but the general gist is right. -Tim 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
RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)
My only objection is that this will cause key generation to shift to partners and affiliates, who will almost certainly do an even worse job. If you want to ban key generation by anyone but the end entity, ban key generation by anyone but the end entity. -Tim > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Wayne > Thayer via dev-security-policy > Sent: Tuesday, May 15, 2018 4:10 PM > To: Dimitris Zacharopoulos > Cc: mozilla-dev-security-policy > > Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key > generation to policy) > > I'm coming to the conclusion that this discussion is about "security > theater"[1]. > As long as we allow CAs to generate S/MIME key pairs, there are gaping holes > in the PKCS#12 requirements, the most obvious being that a CA can just > transfer the private key to the user in pem format! Are there any objections > to > dropping the PKCS#12 requirements altogether and just forbidding key > generation for TLS certificates as follows? > > CAs MUST NOT generate the key pairs for end-entity certificates that have an > EKU extension containing the KeyPurposeIds id-kp-serverAuth or > anyExtendedKeyUsage. > > - Wayne > > [1] https://en.wikipedia.org/wiki/Security_theater > > On Tue, May 15, 2018 at 10:23 AM Dimitris Zacharopoulos > wrote: > > > > > > > On 15/5/2018 6:51 μμ, Wayne Thayer via dev-security-policy wrote: > > > > Did you consider any changes based on Jakob’s comments? If the > > PKCS#12 is distributed via secure channels, how strong does the password > need to be? > > > > > > > > > > > > I think this depends on our threat model, which to be fair is not > > something we've defined. If we're only concerned with protecting the > > delivery of the > > PKCS#12 file to the user, then this makes sense. If we're also > > concerned with protection of the file while in possession of the user, > > then a strong password makes sense regardless of the delivery mechanism. > > > > > > I think once the key material is securely delivered to the user, it is > > no longer under the CA's control and we shouldn't assume that it is. > > The user might change the passphrase of the PKCS#12 file to whatever, > > or store the private key without any encryption. > > > > > > Dimitris. > > > ___ > 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
Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)
I'm coming to the conclusion that this discussion is about "security theater"[1]. As long as we allow CAs to generate S/MIME key pairs, there are gaping holes in the PKCS#12 requirements, the most obvious being that a CA can just transfer the private key to the user in pem format! Are there any objections to dropping the PKCS#12 requirements altogether and just forbidding key generation for TLS certificates as follows? CAs MUST NOT generate the key pairs for end-entity certificates that have an EKU extension containing the KeyPurposeIds id-kp-serverAuth or anyExtendedKeyUsage. - Wayne [1] https://en.wikipedia.org/wiki/Security_theater On Tue, May 15, 2018 at 10:23 AM Dimitris Zacharopoulos wrote: > > > On 15/5/2018 6:51 μμ, Wayne Thayer via dev-security-policy wrote: > > Did you consider any changes based on Jakob’s comments? If the PKCS#12 is > distributed via secure channels, how strong does the password need to be? > > > > > > I think this depends on our threat model, which to be fair is not something > we've defined. If we're only concerned with protecting the delivery of the > PKCS#12 file to the user, then this makes sense. If we're also concerned > with protection of the file while in possession of the user, then a strong > password makes sense regardless of the delivery mechanism. > > > I think once the key material is securely delivered to the user, it is no > longer under the CA's control and we shouldn't assume that it is. The user > might change the passphrase of the PKCS#12 file to whatever, or store the > private key without any encryption. > > > Dimitris. > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)
On 15/5/2018 6:51 μμ, Wayne Thayer via dev-security-policy wrote: Did you consider any changes based on Jakob’s comments? If the PKCS#12 is distributed via secure channels, how strong does the password need to be? I think this depends on our threat model, which to be fair is not something we've defined. If we're only concerned with protecting the delivery of the PKCS#12 file to the user, then this makes sense. If we're also concerned with protection of the file while in possession of the user, then a strong password makes sense regardless of the delivery mechanism. I think once the key material is securely delivered to the user, it is no longer under the CA's control and we shouldn't assume that it is. The user might change the passphrase of the PKCS#12 file to whatever, or store the private key without any encryption. Dimitris. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)
On Tue, May 15, 2018 at 7:51 AM Doug Beattie wrote: > Wayne, > > > > This going to require 19 randomly generated Base64 characters and that > does not include removing common confused characters which will drive up > the length a bit more, but if this is what the Mozilla risk assessment came > up with, then we’ll all have to comply. > > As discussed earlier in this thread, 112 bits of entropy is not something we just made up. It's grounded in guidance from NIST and other industry bodies. > > I hope there is a sufficiently long time for CAs to change their > processes and APIs and to roll out updated training and documentation to > their customers (for this unplanned change). > > > > I'll propose January 1, 2019 as the effective date. > > Did you consider any changes based on Jakob’s comments? If the PKCS#12 is > distributed via secure channels, how strong does the password need to be? > > > > I think this depends on our threat model, which to be fair is not something we've defined. If we're only concerned with protecting the delivery of the PKCS#12 file to the user, then this makes sense. If we're also concerned with protection of the file while in possession of the user, then a strong password makes sense regardless of the delivery mechanism. > > Doug > > > > > > > > *From:* Wayne Thayer [mailto:wtha...@mozilla.com] > *Sent:* Monday, May 14, 2018 4:54 PM > *To:* Doug Beattie ; > mozilla-dev-security-policy > > *Subject:* Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on > CA key generation to policy) > > > > On Mon, May 14, 2018 at 11:50 AM Doug Beattie via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > I hope some other CAs weigh in in this: Robin, Bruce, Jeremy, Daymion, > Dean??? > - We can’t permit user generated passwords (at least that is Tim's > proposal, Wayne may not agree yet but he will when he reads this email) > - We can’t distribute both the password and PKCS#12 over the same channel, > even if it's a secure channel like HTTPS > > We have 2 choices for where the password is generated: CA or User > > > > > Or the user could generate the key :-) > > > > > 1) If we require CAs to generate the passwords and they can’t distribute > the necessary information to the end user via the portal over TLS (because > of the dual channel requirement), then that is a relatively large impact on > us, and probably anyone else that supports PKCS#12 file formats. If the > channel is secure, do you need to use different channels? > > > 2) Trying to compute the entropy of a user generated password is nearly > impossible. According to NIST Special Publication 800-63, a good 20 > character password will have just 48 bits of entropy, and characters after > that only add 1 bite of entropy each. User stink at generating Entropy > (right Tim?) > > NIST Special Publication 800-63 of June 2004 (revision 2) suggested the > following scheme to roughly estimate the entropy of human-generated > passwords (Subsequent updates of this publication gave up trying to compute > entropy for user generated passwords, and when they talk about entropy they > talk about 20 bits max): > • The entropy of the first character is four bits; > • The entropy of the next seven characters are two bits per > character; > • The ninth through the twentieth character has 1.5 bits of entropy > per character; > • Characters 21 and above have one bit of entropy per character. > • A "bonus" of six bits is added if both upper case letters and > non-alphabetic characters are used. > • A "bonus" of six bits is added for passwords of length 1 through > 19 characters following an extensive dictionary check to ensure the > password is not contained within a large dictionary. Passwords of 20 > characters or more do not receive this bonus because it is assumed they are > pass-phrases consisting of multiple dictionary words. > > https://pages.nist.gov/800-63-3/ > > Some CAs are probably asking the user for a password during the request > thus there is no need to distribute it later. But, if the Applicant > provides the password over HTTPS and then later the CA provides the PKCS#12 > via download link and they obtain it via HTTPS, is that a single channel > that they were both distributed over? > > I still object to not being able to use HTTPS for collection and/or > distribution of the Password and the PKCS#12. I also believe 112 bits of > entropy is way too much for user generated password (assuming we want to > continue supporting that option). > > Perhaps the following language
RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)
Wayne, This going to require 19 randomly generated Base64 characters and that does not include removing common confused characters which will drive up the length a bit more, but if this is what the Mozilla risk assessment came up with, then we’ll all have to comply. I hope there is a sufficiently long time for CAs to change their processes and APIs and to roll out updated training and documentation to their customers (for this unplanned change). Did you consider any changes based on Jakob’s comments? If the PKCS#12 is distributed via secure channels, how strong does the password need to be? Doug From: Wayne Thayer [mailto:wtha...@mozilla.com] Sent: Monday, May 14, 2018 4:54 PM To: Doug Beattie ; mozilla-dev-security-policy Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy) On Mon, May 14, 2018 at 11:50 AM Doug Beattie via dev-security-policy mailto:dev-security-policy@lists.mozilla.org>> wrote: I hope some other CAs weigh in in this: Robin, Bruce, Jeremy, Daymion, Dean??? - We can’t permit user generated passwords (at least that is Tim's proposal, Wayne may not agree yet but he will when he reads this email) - We can’t distribute both the password and PKCS#12 over the same channel, even if it's a secure channel like HTTPS We have 2 choices for where the password is generated: CA or User > Or the user could generate the key :-) > 1) If we require CAs to generate the passwords and they can’t distribute the necessary information to the end user via the portal over TLS (because of the dual channel requirement), then that is a relatively large impact on us, and probably anyone else that supports PKCS#12 file formats. If the channel is secure, do you need to use different channels? 2) Trying to compute the entropy of a user generated password is nearly impossible. According to NIST Special Publication 800-63, a good 20 character password will have just 48 bits of entropy, and characters after that only add 1 bite of entropy each. User stink at generating Entropy (right Tim?) NIST Special Publication 800-63 of June 2004 (revision 2) suggested the following scheme to roughly estimate the entropy of human-generated passwords (Subsequent updates of this publication gave up trying to compute entropy for user generated passwords, and when they talk about entropy they talk about 20 bits max): • The entropy of the first character is four bits; • The entropy of the next seven characters are two bits per character; • The ninth through the twentieth character has 1.5 bits of entropy per character; • Characters 21 and above have one bit of entropy per character. • A "bonus" of six bits is added if both upper case letters and non-alphabetic characters are used. • A "bonus" of six bits is added for passwords of length 1 through 19 characters following an extensive dictionary check to ensure the password is not contained within a large dictionary. Passwords of 20 characters or more do not receive this bonus because it is assumed they are pass-phrases consisting of multiple dictionary words. https://pages.nist.gov/800-63-3/ Some CAs are probably asking the user for a password during the request thus there is no need to distribute it later. But, if the Applicant provides the password over HTTPS and then later the CA provides the PKCS#12 via download link and they obtain it via HTTPS, is that a single channel that they were both distributed over? I still object to not being able to use HTTPS for collection and/or distribution of the Password and the PKCS#12. I also believe 112 bits of entropy is way too much for user generated password (assuming we want to continue supporting that option). Perhaps the following language is a workable solution to the first objection? PKCS#12 files must employ an encryption key and algorithm that is sufficiently strong to protect the key pair for its useful life based on current guidelines published by a recognized standards body. PKCS#12 files MUST be encrypted and signed; or, MUST have a password that exhibits at least 112 bits of entropy, and the password MUST be transmitted via a secure channel. I really don't seem a benefit to user generation of these passwords - either they are weak and memorable, or sufficiently complicated that there's little value in being able to choose it. Doug ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)
On 14/05/2018 22:53, Wayne Thayer wrote: On Mon, May 14, 2018 at 11:50 AM Doug Beattie via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: I hope some other CAs weigh in in this: Robin, Bruce, Jeremy, Daymion, Dean??? - We can’t permit user generated passwords (at least that is Tim's proposal, Wayne may not agree yet but he will when he reads this email) - We can’t distribute both the password and PKCS#12 over the same channel, even if it's a secure channel like HTTPS We have 2 choices for where the password is generated: CA or User Or the user could generate the key :-) 1) If we require CAs to generate the passwords and they can’t distribute the necessary information to the end user via the portal over TLS (because of the dual channel requirement), then that is a relatively large impact on us, and probably anyone else that supports PKCS#12 file formats. If the channel is secure, do you need to use different channels? 2) Trying to compute the entropy of a user generated password is nearly impossible. According to NIST Special Publication 800-63, a good 20 character password will have just 48 bits of entropy, and characters after that only add 1 bite of entropy each. User stink at generating Entropy (right Tim?) NIST Special Publication 800-63 of June 2004 (revision 2) suggested the following scheme to roughly estimate the entropy of human-generated passwords (Subsequent updates of this publication gave up trying to compute entropy for user generated passwords, and when they talk about entropy they talk about 20 bits max): • The entropy of the first character is four bits; • The entropy of the next seven characters are two bits per character; • The ninth through the twentieth character has 1.5 bits of entropy per character; • Characters 21 and above have one bit of entropy per character. • A "bonus" of six bits is added if both upper case letters and non-alphabetic characters are used. • A "bonus" of six bits is added for passwords of length 1 through 19 characters following an extensive dictionary check to ensure the password is not contained within a large dictionary. Passwords of 20 characters or more do not receive this bonus because it is assumed they are pass-phrases consisting of multiple dictionary words. https://pages.nist.gov/800-63-3/ Some CAs are probably asking the user for a password during the request thus there is no need to distribute it later. But, if the Applicant provides the password over HTTPS and then later the CA provides the PKCS#12 via download link and they obtain it via HTTPS, is that a single channel that they were both distributed over? I still object to not being able to use HTTPS for collection and/or distribution of the Password and the PKCS#12. I also believe 112 bits of entropy is way too much for user generated password (assuming we want to continue supporting that option). Perhaps the following language is a workable solution to the first objection? PKCS#12 files must employ an encryption key and algorithm that is sufficiently strong to protect the key pair for its useful life based on current guidelines published by a recognized standards body. PKCS#12 files MUST be encrypted and signed; or, MUST have a password that exhibits at least 112 bits of entropy, and the password MUST be transmitted via a secure channel. I really don't seem a benefit to user generation of these passwords - either they are weak and memorable, or sufficiently complicated that there's little value in being able to choose it. Maybe reconsider the idea of extending the PKCS#12 key length rules from insecure to secure channels. In other words, if the channel itself is sufficiently secure to allow distribution of the key in a format with no encryption of its own, then there maybe shouldn't be additional requirements for the PKCS#12 file. Also consider the issue of key generation for individual users by a constrained SubCAs belonging to an organization. Here the private key generation and protection may be handled by the organization internal security and encryption channels, that bear little resemblance to the 3rd party CA scenario. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)
On Mon, May 14, 2018 at 11:50 AM Doug Beattie via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I hope some other CAs weigh in in this: Robin, Bruce, Jeremy, Daymion, > Dean??? > - We can’t permit user generated passwords (at least that is Tim's > proposal, Wayne may not agree yet but he will when he reads this email) > - We can’t distribute both the password and PKCS#12 over the same channel, > even if it's a secure channel like HTTPS > > We have 2 choices for where the password is generated: CA or User > > > Or the user could generate the key :-) > > 1) If we require CAs to generate the passwords and they can’t distribute > the necessary information to the end user via the portal over TLS (because > of the dual channel requirement), then that is a relatively large impact on > us, and probably anyone else that supports PKCS#12 file formats. If the > channel is secure, do you need to use different channels? > > > 2) Trying to compute the entropy of a user generated password is nearly > impossible. According to NIST Special Publication 800-63, a good 20 > character password will have just 48 bits of entropy, and characters after > that only add 1 bite of entropy each. User stink at generating Entropy > (right Tim?) > > NIST Special Publication 800-63 of June 2004 (revision 2) suggested the > following scheme to roughly estimate the entropy of human-generated > passwords (Subsequent updates of this publication gave up trying to compute > entropy for user generated passwords, and when they talk about entropy they > talk about 20 bits max): > • The entropy of the first character is four bits; > • The entropy of the next seven characters are two bits per > character; > • The ninth through the twentieth character has 1.5 bits of entropy > per character; > • Characters 21 and above have one bit of entropy per character. > • A "bonus" of six bits is added if both upper case letters and > non-alphabetic characters are used. > • A "bonus" of six bits is added for passwords of length 1 through > 19 characters following an extensive dictionary check to ensure the > password is not contained within a large dictionary. Passwords of 20 > characters or more do not receive this bonus because it is assumed they are > pass-phrases consisting of multiple dictionary words. > > https://pages.nist.gov/800-63-3/ > > Some CAs are probably asking the user for a password during the request > thus there is no need to distribute it later. But, if the Applicant > provides the password over HTTPS and then later the CA provides the PKCS#12 > via download link and they obtain it via HTTPS, is that a single channel > that they were both distributed over? > > I still object to not being able to use HTTPS for collection and/or > distribution of the Password and the PKCS#12. I also believe 112 bits of > entropy is way too much for user generated password (assuming we want to > continue supporting that option). > > Perhaps the following language is a workable solution to the first objection? PKCS#12 files must employ an encryption key and algorithm that is sufficiently strong to protect the key pair for its useful life based on current guidelines published by a recognized standards body. PKCS#12 files MUST be encrypted and signed; or, MUST have a password that exhibits at least 112 bits of entropy, and the password MUST be transmitted via a secure channel. I really don't seem a benefit to user generation of these passwords - either they are weak and memorable, or sufficiently complicated that there's little value in being able to choose it. Doug > > > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: FW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)
On Mon, May 14, 2018 at 11:29 AM Bruce via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Wednesday, May 9, 2018 at 11:42:56 PM UTC-4, Wayne Thayer wrote: > > I think we have settled on the following resolution to this issue: > > > > Add the following to section 5.2 (Forbidden and Required Practices): > > > > CAs MUST NOT generate the key pairs for end-entity certificates that have > > > an EKU extension containing the KeyPurposeIds id-kp-serverAuth or > > > anyExtendedKeyUsage. > > > > > > PKCS#12 files must employ an encryption key and algorithm that is > > > sufficiently strong to protect the key pair for its useful life based > on > > > current guidelines published by a recognized standards body. PKCS#12 > files > > > MUST be encrypted and signed; or, MUST have a password that exhibits at > > > least 112 bits of entropy, and the password MUST be transferred using a > > > different channel than the PKCS#12 file. > > > > > > > Unless there is further discussion, I will include this language in the > > final version of the policy. > > > > - Wayne > > In one use case, the Subscriber can create their own password to start the > enrollment process for the S/MIME certificate. The P12 is created, > encrypted and sent to the Subscriber to be decrypted using the password. I > think that asking the Subscriber to create a password with 112-bits entropy > may create a very long password (over 20 characters). I think that this > will take much longer than the life of the certificate (or its user) to > crack. This password may also be recorded improperly or recorded on the > same device as the key will reside. Could we consider reducing the size of > the password? > > Remember that this only applies when the CA generates the key pair. If the CA must for some reason do that, then it's reasonable to expect the CA to secure it with a strong password. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)
I hope some other CAs weigh in in this: Robin, Bruce, Jeremy, Daymion, Dean??? - We can’t permit user generated passwords (at least that is Tim's proposal, Wayne may not agree yet but he will when he reads this email) - We can’t distribute both the password and PKCS#12 over the same channel, even if it's a secure channel like HTTPS We have 2 choices for where the password is generated: CA or User 1) If we require CAs to generate the passwords and they can’t distribute the necessary information to the end user via the portal over TLS (because of the dual channel requirement), then that is a relatively large impact on us, and probably anyone else that supports PKCS#12 file formats. If the channel is secure, do you need to use different channels? 2) Trying to compute the entropy of a user generated password is nearly impossible. According to NIST Special Publication 800-63, a good 20 character password will have just 48 bits of entropy, and characters after that only add 1 bite of entropy each. User stink at generating Entropy (right Tim?) NIST Special Publication 800-63 of June 2004 (revision 2) suggested the following scheme to roughly estimate the entropy of human-generated passwords (Subsequent updates of this publication gave up trying to compute entropy for user generated passwords, and when they talk about entropy they talk about 20 bits max): • The entropy of the first character is four bits; • The entropy of the next seven characters are two bits per character; • The ninth through the twentieth character has 1.5 bits of entropy per character; • Characters 21 and above have one bit of entropy per character. • A "bonus" of six bits is added if both upper case letters and non-alphabetic characters are used. • A "bonus" of six bits is added for passwords of length 1 through 19 characters following an extensive dictionary check to ensure the password is not contained within a large dictionary. Passwords of 20 characters or more do not receive this bonus because it is assumed they are pass-phrases consisting of multiple dictionary words. https://pages.nist.gov/800-63-3/ Some CAs are probably asking the user for a password during the request thus there is no need to distribute it later. But, if the Applicant provides the password over HTTPS and then later the CA provides the PKCS#12 via download link and they obtain it via HTTPS, is that a single channel that they were both distributed over? I still object to not being able to use HTTPS for collection and/or distribution of the Password and the PKCS#12. I also believe 112 bits of entropy is way too much for user generated password (assuming we want to continue supporting that option). Doug > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of Tim > Hollebeek via dev-security-policy > Sent: Monday, May 14, 2018 12:52 PM > To: Ryan Hurst ; mozilla-dev-security- > pol...@lists.mozilla.org > Subject: RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key > generation to policy) > > For the record, I posted someone else's strength testing algorithm, and > pointed out that it was bad 😊 I personally don't think building strength > testing > algorithms is hopeless, and I think good ones are very useful. I tend to > agree > with the current NIST recommendation, which is to primarily only consider > length, along with things like history, dictionary words, and reuse. > > But in this case, the public is at risk if the key is compromised, so I don't > trust a > password chosen by an end user, no matter what strength function it may or > may not pass. > > Some form of random password of sufficient length, with the randomness > coming from a CSPRNG, encoded into a more user friendly form, is the right > answer here. > > -Tim > > > -Original Message- > > From: dev-security-policy [mailto:dev-security-policy- > > bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of > > bounces+Ryan > > Hurst via dev-security-policy > > Sent: Friday, May 4, 2018 5:19 PM > > To: mozilla-dev-security-pol...@lists.mozilla.org > > Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on > > CA key generation to policy) > > > > > > > True, but CAs can put technical constraints on that to limit the > > > acceptable > > passwords to a certain strength. (hopefully with a better > > strength-testing algorithm than the example Tim gave earlier) > > > > Tim is the best of us -- this is hard to do well :) > > > > _
Re: FW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)
On Wednesday, May 9, 2018 at 11:42:56 PM UTC-4, Wayne Thayer wrote: > I think we have settled on the following resolution to this issue: > > Add the following to section 5.2 (Forbidden and Required Practices): > > CAs MUST NOT generate the key pairs for end-entity certificates that have > > an EKU extension containing the KeyPurposeIds id-kp-serverAuth or > > anyExtendedKeyUsage. > > > > PKCS#12 files must employ an encryption key and algorithm that is > > sufficiently strong to protect the key pair for its useful life based on > > current guidelines published by a recognized standards body. PKCS#12 files > > MUST be encrypted and signed; or, MUST have a password that exhibits at > > least 112 bits of entropy, and the password MUST be transferred using a > > different channel than the PKCS#12 file. > > > > Unless there is further discussion, I will include this language in the > final version of the policy. > > - Wayne In one use case, the Subscriber can create their own password to start the enrollment process for the S/MIME certificate. The P12 is created, encrypted and sent to the Subscriber to be decrypted using the password. I think that asking the Subscriber to create a password with 112-bits entropy may create a very long password (over 20 characters). I think that this will take much longer than the life of the certificate (or its user) to crack. This password may also be recorded improperly or recorded on the same device as the key will reside. Could we consider reducing the size of the password? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)
For the record, I posted someone else's strength testing algorithm, and pointed out that it was bad 😊 I personally don't think building strength testing algorithms is hopeless, and I think good ones are very useful. I tend to agree with the current NIST recommendation, which is to primarily only consider length, along with things like history, dictionary words, and reuse. But in this case, the public is at risk if the key is compromised, so I don't trust a password chosen by an end user, no matter what strength function it may or may not pass. Some form of random password of sufficient length, with the randomness coming from a CSPRNG, encoded into a more user friendly form, is the right answer here. -Tim > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Ryan > Hurst via dev-security-policy > Sent: Friday, May 4, 2018 5:19 PM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key > generation to policy) > > > > True, but CAs can put technical constraints on that to limit the acceptable > passwords to a certain strength. (hopefully with a better strength-testing > algorithm than the example Tim gave earlier) > > Tim is the best of us -- this is hard to do well :) > > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://clicktime.symantec.com/a/1/B4EQCI- > M91W3VFdrYnu8NKa6AWUA0Oca9gCvph6YNAo=?d=1AFyDzj7qs0LPt1qH7YZK > X7VDlKTG3u4_pF-smh1LdxQUjK6Fx2ySSFy5RdxazxX- > o23v3NFfmxRdpLUwPqiW6yozAgZPzuSbInOcX3x3V3ANyskgECX5k4aeBDO0z1u > RHJpH- > Wb5WOBjb0n16kco9wf4jRlCIO7HgEH4pMHjx4H_POUivn493OPB7U9RX8BArU > 5U87OFuHYndlG0UK-XvQOKqKu6t_3fatFfevp7IT8Jzm4Ze- > xwk8jgsytRsxvWQ561mB9wFaxsYkiFLZMBHmsNDACgJKZxHouitR-aXhUbxF- > fKeFXogKbfDCYiYLqHOe5i8KyS8AzFNsUaZTDGJisXeUJbui5n9H3tF5berZe0DuntP > V7a9yad9- > haeyu7NspHh92Niu71JNcWZks3gkKolxwuU9vUfZCdfiIIhMHniPOMkCkMl0ooM > gbRFl0gnAgmiNcKuIizRC9Z35_snt4pKSXAU12MQLeTdYFZMGmKYEDTvkB2L_So > 3AZHYfUXATSUeQQlo1zSRKZ5Mapw%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
Re: FW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)
Doug, On Thu, May 10, 2018 at 10:57 AM Doug Beattie wrote: > Hi Wayne, > > > > I’m OK with this as long as this permits the password (fully or partially > generated by the CA) and PKCS#12 file to be picked up by a user over HTTPS > (a single channel). > > > This language is not intended to permit both the password and PKCS#12 file to be transmitted over HTTPS. In an earlier message I said that I'd like to hear from other CAs who feel that this exception is necessary, but none have commented. Given the difficultly in carving out an exception limited to the scenario you described and the [perhaps marginal] increase in security that this requirement provides even in your scenario, I'm not inclined to try to accommodate it. If the proposed language is not clear in stating that the password and PKCS#12 file cannot both be transmitted over HTTPS, please let me know. Doug > > > > > > *From:* Wayne Thayer [mailto:wtha...@mozilla.com] > *Sent:* Wednesday, May 9, 2018 11:43 PM > *To:* Doug Beattie > *Cc:* mozilla-dev-security-policy < > mozilla-dev-security-pol...@lists.mozilla.org> > *Subject:* Re: FW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition > on CA key generation to policy) > > > > > > I think we have settled on the following resolution to this issue: > > > > Add the following to section 5.2 (Forbidden and Required Practices): > > > > CAs MUST NOT generate the key pairs for end-entity certificates that have > an EKU extension containing the KeyPurposeIds id-kp-serverAuth or > > anyExtendedKeyUsage. > > > > PKCS#12 files must employ an encryption key and algorithm that is > sufficiently strong to protect the key pair for its useful life based on > current guidelines published by a recognized standards body. PKCS#12 files > MUST be encrypted and signed; or, MUST have a password that exhibits at > least 112 bits of entropy, and the password MUST be transferred using a > different channel than the PKCS#12 file. > > > > Unless there is further discussion, I will include this language in the > final version of the policy. > > > > - Wayne > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: FW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)
Hi Wayne, I’m OK with this as long as this permits the password (fully or partially generated by the CA) and PKCS#12 file to be picked up by a user over HTTPS (a single channel). Doug From: Wayne Thayer [mailto:wtha...@mozilla.com] Sent: Wednesday, May 9, 2018 11:43 PM To: Doug Beattie Cc: mozilla-dev-security-policy Subject: Re: FW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy) I think we have settled on the following resolution to this issue: Add the following to section 5.2 (Forbidden and Required Practices): CAs MUST NOT generate the key pairs for end-entity certificates that have an EKU extension containing the KeyPurposeIds id-kp-serverAuth or anyExtendedKeyUsage. PKCS#12 files must employ an encryption key and algorithm that is sufficiently strong to protect the key pair for its useful life based on current guidelines published by a recognized standards body. PKCS#12 files MUST be encrypted and signed; or, MUST have a password that exhibits at least 112 bits of entropy, and the password MUST be transferred using a different channel than the PKCS#12 file. Unless there is further discussion, I will include this language in the final version of the policy. - Wayne ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: FW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)
I think we have settled on the following resolution to this issue: Add the following to section 5.2 (Forbidden and Required Practices): CAs MUST NOT generate the key pairs for end-entity certificates that have > an EKU extension containing the KeyPurposeIds id-kp-serverAuth or > anyExtendedKeyUsage. > > PKCS#12 files must employ an encryption key and algorithm that is > sufficiently strong to protect the key pair for its useful life based on > current guidelines published by a recognized standards body. PKCS#12 files > MUST be encrypted and signed; or, MUST have a password that exhibits at > least 112 bits of entropy, and the password MUST be transferred using a > different channel than the PKCS#12 file. > Unless there is further discussion, I will include this language in the final version of the policy. - Wayne ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
FW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)
>From: Wayne Thayer [mailto:wtha...@mozilla.com] >Sent: Monday, May 7, 2018 8:43 PM >To: Doug Beattie >Cc: Ryan Hurst ; mozilla-dev-security-policy >pol...@lists.mozilla.org> >Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key >generation to policy) > >Doug, > >On Mon, May 7, 2018 at 11:24 AM Doug Beattie via dev-security-policy ><mailto:dev-security->pol...@lists.mozilla.org> wrote: >> -Original Message- >> From: dev-security-policy [mailto:mailto:dev-security-policy- >> bounces+doug.beattie=mailto:globalsign@lists.mozilla.org] On Behalf Of >> Ryan >> Hurst via dev-security-policy >> Sent: Friday, May 4, 2018 4:35 PM >> To: mailto:mozilla-dev-security-pol...@lists.mozilla.org >> Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key >> generation to policy) >> >> On Friday, May 4, 2018 at 1:00:03 PM UTC-7, Doug Beattie wrote: >> > First comments on this: "MUST be encrypted and signed; or, MUST have a >> password that..." >> > - Isn't the password the key used for encryption? I'm not sure if the "or" >> makes sense since in both cases the password is the key for encryption >> >> There are modes of PKCS#12 that do not use passwords. >If you're stating that we should include the use of PKCS#12 that don't use >passwords and that are >encrupted, then we need to define the parameters of the key used for that >purpose, > >Would it be enough to say that "PKCS#12 files must employ an encryption key >and algorithm that is >sufficiently strong..." (add "key and")? Sure, that works for me. >> > - In general, I don't think PKCS#12 files are signed, so I'd leave that >> > out, a >> signature isn't necessary. I could be wrong... >> >> They may be, see: http://unmitigatedrisk.com/?p=543 >The requirement seems to imply it must be signed, and I don't think we want >that, do we? I think >should remove "or signed" and that will permit them to be signed, but not >require it. > > That's not hoe I read it. The proposed language provides the option of >'encrypted and signed' or >protected with a password'. Since your use case is 'protected with a >password', there is no requirement >for the file to be signed. OK >> >> > >> > I'd still like to see a modification on the requirement: "password MUST be >> transferred using a different channel than the PKCS#12 file". A user should >> be >> able to download the P12 and password via HTTP. Can we add an exception >> for that? >> >> Why do you want to allow the use of HTTP? >Sorry, I meant HTTPS. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)
Doug, On Mon, May 7, 2018 at 11:24 AM Doug Beattie via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > -Original Message- > > From: dev-security-policy [mailto:dev-security-policy- > > bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of Ryan > > Hurst via dev-security-policy > > Sent: Friday, May 4, 2018 4:35 PM > > To: mozilla-dev-security-pol...@lists.mozilla.org > > Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on > CA key > > generation to policy) > > > > On Friday, May 4, 2018 at 1:00:03 PM UTC-7, Doug Beattie wrote: > > > First comments on this: "MUST be encrypted and signed; or, MUST have a > > password that..." > > > - Isn't the password the key used for encryption? I'm not sure if the > "or" > > makes sense since in both cases the password is the key for encryption > > > > There are modes of PKCS#12 that do not use passwords. > If you're stating that we should include the use of PKCS#12 that don't use > passwords and that are encrupted, then we need to define the parameters of > the key used for that purpose, > > > Would it be enough to say that "PKCS#12 files must employ an encryption key and algorithm that is sufficiently strong..." (add "key and")? > > > > - In general, I don't think PKCS#12 files are signed, so I'd leave > that out, a > > signature isn't necessary. I could be wrong... > > > > They may be, see: http://unmitigatedrisk.com/?p=543 > The requirement seems to imply it must be signed, and I don't think we > want that, do we? I think should remove "or signed" and that will permit > them to be signed, but not require it. > > That's not hoe I read it. The proposed language provides the option of 'encrypted and signed' or 'protected with a password'. Since your use case is 'protected with a password', there is no requirement for the file to be signed. > > > > > > > I'd still like to see a modification on the requirement: "password > MUST be > > transferred using a different channel than the PKCS#12 file". A user > should be > > able to download the P12 and password via HTTP. Can we add an exception > > for that? > > > > Why do you want to allow the use of HTTP? > Sorry, I meant HTTPS. > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)
> -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of Ryan > Hurst via dev-security-policy > Sent: Friday, May 4, 2018 4:35 PM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key > generation to policy) > > On Friday, May 4, 2018 at 1:00:03 PM UTC-7, Doug Beattie wrote: > > First comments on this: "MUST be encrypted and signed; or, MUST have a > password that..." > > - Isn't the password the key used for encryption? I'm not sure if the "or" > makes sense since in both cases the password is the key for encryption > > There are modes of PKCS#12 that do not use passwords. If you're stating that we should include the use of PKCS#12 that don't use passwords and that are encrupted, then we need to define the parameters of the key used for that purpose, > > - In general, I don't think PKCS#12 files are signed, so I'd leave that > > out, a > signature isn't necessary. I could be wrong... > > They may be, see: http://unmitigatedrisk.com/?p=543 The requirement seems to imply it must be signed, and I don't think we want that, do we? I think should remove "or signed" and that will permit them to be signed, but not require it. > > > > I'd still like to see a modification on the requirement: "password MUST be > transferred using a different channel than the PKCS#12 file". A user should > be > able to download the P12 and password via HTTP. Can we add an exception > for that? > > Why do you want to allow the use of HTTP? Sorry, I meant HTTPS. > ___ > 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
Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)
On 04/05/2018 20:58, Wayne Thayer wrote: The optimist in me thinks we might be getting close to resolving this issue (the last one remaining for the 2.6 policy update). Here is another proposal that attempts to account for most of the input we've received: Add the following to section 5.2 (Forbidden and Required Practices): CAs MUST NOT generate the key pairs for end-entity certificates that have an EKU extension containing the KeyPurposeIds id-kp-serverAuth or anyExtendedKeyUsage. PKCS#12 files must employ an encryption algorithm that is sufficiently strong to protect the key pair for its useful life based on current guidelines published by a recognized standards body. PKCS#12 files MUST be encrypted and signed; or, MUST have a password that exhibits at least 112 bits of entropy, and the password MUST be transferred using a different channel than the PKCS#12 file. This isn't perfect. I would appreciate your comments if you have significant concerns with this proposed policy. - Wayne Given the fiasco of at least one major PKCS#12 implementation only allowing embarrassingly weak encryption, while simultaneously insisting on not accepting other private key import formats: Wouldn't it be prudent to allow transport of PKCS#12 files (with weak compatible encryption) inside a much stronger encrypted container such as a strongly encrypted S/MIME message or a strongly encrypted TLS transmission (HTTPS, LDAPS etc.). The idea being that the weak PKCS#12 encryption is not treated as the private key protection, but merely as a file format artifact. I have previously given a (hypothetical) example of a procedure that relies on tamper-evident physical envelopes rather than cryptography to protect the private key delivery. That would be another example of using a different mechanism than PKCS#12 encryption for turning an insecure channel into a secure private key delivery mechanism. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)
> True, but CAs can put technical constraints on that to limit the acceptable > passwords to a certain strength. (hopefully with a better strength-testing > algorithm than the example Tim gave earlier) Tim is the best of us -- this is hard to do well :) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)
On Friday, May 4, 2018 at 3:37:10 PM UTC-5, Ryan Hurst wrote: > > > > What about "or a user supplied password"? > > -carl > > user supplied passwords will (in real world scenarios) not be as good as a > one generated for them; this is in part why I suggested earlier if a user > password to be used that it be mixed with a server provided value. True, but CAs can put technical constraints on that to limit the acceptable passwords to a certain strength. (hopefully with a better strength-testing algorithm than the example Tim gave earlier) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)
On Fri, May 4, 2018 at 1:25 PM Carl Mehner via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hey Doug, > > On Friday, May 4, 2018 at 3:00:03 PM UTC-5, Doug Beattie wrote: > > Hey Wayne, > > > > This should be a really easy thing, but it's not. > > > > First comments on this: "MUST be encrypted and signed; or, MUST have a > password that..." > > - Isn't the password the key used for encryption? I'm not sure if the > "or" makes sense since in both cases the password is the key for encryption > > The password is used through a round of hashes (or a pbkdf, depending on > the algorithm) to create a set of bits that are used as a key. (see > paragraph 6 here: https://www.cem.me/20150315-cert-binaries-6.html) > > > - In general, I don't think PKCS#12 files are signed, so I'd leave that > out, a signature isn't necessary. I could be wrong... > > That goes back to Ryan's comment here: > > https://groups.google.com/d/msg/mozilla.dev.security.policy/SYC0d1YgXtI/slRunsYbAgAJ > "PKCS#12 supports both symmetric and asymmetric key based protection also." > > > Yes, that is the intent. If my wording is poor, please suggest improvements. > > > > > I'd still like to see a modification on the requirement: "password MUST > be transferred using a different channel than the PKCS#12 file". A user > should be able to download the P12 and password via HTTP. Can we add an > exception for that? > > > I'd like to hear from others who think this is needed. > > What about "or a user supplied password"? > > Doesn't the current language already permit this? It does make sense if you're suggesting it to Doug as a workaround. > > -carl > ___ > 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
Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)
> > What about "or a user supplied password"? > -carl user supplied passwords will (in real world scenarios) not be as good as a one generated for them; this is in part why I suggested earlier if a user password to be used that it be mixed with a server provided value. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)
On Friday, May 4, 2018 at 1:00:03 PM UTC-7, Doug Beattie wrote: > First comments on this: "MUST be encrypted and signed; or, MUST have a > password that..." > - Isn't the password the key used for encryption? I'm not sure if the "or" > makes sense since in both cases the password is the key for encryption There are modes of PKCS#12 that do not use passwords. > - In general, I don't think PKCS#12 files are signed, so I'd leave that out, > a signature isn't necessary. I could be wrong... They may be, see: http://unmitigatedrisk.com/?p=543 > > I'd still like to see a modification on the requirement: "password MUST be > transferred using a different channel than the PKCS#12 file". A user should > be able to download the P12 and password via HTTP. Can we add an exception > for that? Why do you want to allow the use of HTTP? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)
Hey Doug, On Friday, May 4, 2018 at 3:00:03 PM UTC-5, Doug Beattie wrote: > Hey Wayne, > > This should be a really easy thing, but it's not. > > First comments on this: "MUST be encrypted and signed; or, MUST have a > password that..." > - Isn't the password the key used for encryption? I'm not sure if the "or" > makes sense since in both cases the password is the key for encryption The password is used through a round of hashes (or a pbkdf, depending on the algorithm) to create a set of bits that are used as a key. (see paragraph 6 here: https://www.cem.me/20150315-cert-binaries-6.html) > - In general, I don't think PKCS#12 files are signed, so I'd leave that out, > a signature isn't necessary. I could be wrong... That goes back to Ryan's comment here: https://groups.google.com/d/msg/mozilla.dev.security.policy/SYC0d1YgXtI/slRunsYbAgAJ "PKCS#12 supports both symmetric and asymmetric key based protection also." > I'd still like to see a modification on the requirement: "password MUST be > transferred using a different channel than the PKCS#12 file". A user should > be able to download the P12 and password via HTTP. Can we add an exception > for that? What about "or a user supplied password"? -carl ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)
Hey Wayne, This should be a really easy thing, but it's not. First comments on this: "MUST be encrypted and signed; or, MUST have a password that..." - Isn't the password the key used for encryption? I'm not sure if the "or" makes sense since in both cases the password is the key for encryption - In general, I don't think PKCS#12 files are signed, so I'd leave that out, a signature isn't necessary. I could be wrong... I'd still like to see a modification on the requirement: "password MUST be transferred using a different channel than the PKCS#12 file". A user should be able to download the P12 and password via HTTP. Can we add an exception for that? Doug > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of Wayne > Thayer via dev-security-policy > Sent: Friday, May 4, 2018 2:58 PM > To: mozilla-dev-security-policy > > Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key > generation to policy) > > The optimist in me thinks we might be getting close to resolving this issue > (the > last one remaining for the 2.6 policy update). Here is another proposal that > attempts to account for most of the input we've received: > > Add the following to section 5.2 (Forbidden and Required Practices): > > CAs MUST NOT generate the key pairs for end-entity certificates that have > > an EKU extension containing the KeyPurposeIds id-kp-serverAuth or > > anyExtendedKeyUsage. > > > > PKCS#12 files must employ an encryption algorithm that is sufficiently > > strong to protect the key pair for its useful life based on current > > guidelines published by a recognized standards body. PKCS#12 files > > MUST be encrypted and signed; or, MUST have a password that exhibits > > at least 112 bits of entropy, and the password MUST be transferred > > using a different channel than the PKCS#12 file. > > > > This isn't perfect. I would appreciate your comments if you have significant > concerns with this proposed policy. > > - 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
Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)
The optimist in me thinks we might be getting close to resolving this issue (the last one remaining for the 2.6 policy update). Here is another proposal that attempts to account for most of the input we've received: Add the following to section 5.2 (Forbidden and Required Practices): CAs MUST NOT generate the key pairs for end-entity certificates that have > an EKU extension containing the KeyPurposeIds id-kp-serverAuth or > anyExtendedKeyUsage. > > PKCS#12 files must employ an encryption algorithm that is sufficiently > strong to protect the key pair for its useful life based on current > guidelines published by a recognized standards body. PKCS#12 files MUST be > encrypted and signed; or, MUST have a password that exhibits at least 112 > bits of entropy, and the password MUST be transferred using a different > channel than the PKCS#12 file. > This isn't perfect. I would appreciate your comments if you have significant concerns with this proposed policy. - Wayne ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)
> Maybe you want n = 112 / 8 = 14 bytes. Doh! Yes. -Tim 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
Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)
On 2018-05-04 12:10, Tim Hollebeek wrote: It has generally been understood that a string still "contains at least 112 bits of output from a CSPRNG" if that string has been fed through an encoding mechanism like Base64 or Base32. Furthermore, explicit requirements about including mixed case or special characters leads to some very, very bad and borderline toxic security requirements. NIST has recently recanted and admitted they were very, very wrong in this area and we should not repeat their mistake. Anything we can do to clarify that an awesome password is: string password = Base32.Encode(CSPRNG.ReadBytes(n)); where n >= 112, we should do. Maybe you want n = 112 / 8 = 14 bytes. > BTW United Airlines rates these sorts of passwords as "medium strength". > Password meters that only pay attention to password complexity and not > length are stupid. And then you have sites that have a problem with passwords longer than 12 characters, where you can't the base64 characters. Or where you log in using the number of your card and a pin number limited to 6 digits. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)
It has generally been understood that a string still "contains at least 112 bits of output from a CSPRNG" if that string has been fed through an encoding mechanism like Base64 or Base32. Furthermore, explicit requirements about including mixed case or special characters leads to some very, very bad and borderline toxic security requirements. NIST has recently recanted and admitted they were very, very wrong in this area and we should not repeat their mistake. Anything we can do to clarify that an awesome password is: string password = Base32.Encode(CSPRNG.ReadBytes(n)); where n >= 112, we should do. BTW United Airlines rates these sorts of passwords as "medium strength". Password meters that only pay attention to password complexity and not length are stupid. -Tim > -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: Thursday, May 3, 2018 6:01 PM > To: Carl Mehner ; mozilla-dev-security-pol...@lists.mozilla.org > Subject: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key > generation to policy) > > Basically I like the new wording: > > > PKCS#12 files [...] SHALL have a password containing at least 112 bits > > of output from a CSPRNG, [...] > > But I think there is a practical problem here: Directly using the output of any > random number generator ("C" or not) to generate a password will lead to > passwords which contain most probably characters that are either not > printable or at least not type-able on a 'normal' western style keyboard. > Therefore I think we need to reword the password strength section a little bit, > maybe like the following: > > > PKCS#12 files [...] SHALL have a 14 character long password consisting > > of characters, digits and special characters based on output from a > > CSPRNG, [...] > > When I originally proposed my wording, I had the serial numbers in my mind > (for which directly using the output of a CSPRNG works), but didn't think on the > encoding problem. > > > With best regards, > Rufus Buschart > > 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 Carl Mehner via dev-security-policy > > Gesendet: Mittwoch, 2. Mai 2018 07:45 > > An: mozilla-dev-security-pol...@lists.mozilla.org > > Betreff: Re: Policy 2.6 Proposal: Add prohibition on CA key generation > > to policy > > > > On Tuesday, May 1, 2018 at 6:40:53 PM UTC-5, Wayne Thayer wrote: > > > Ryan - thanks for raising these issues again. I still have concerns > > > about getting this specific in the policy, but since we're now > > > headed down that road... > > > > > > On Tue, May 1, 2018 at 7:13 PM, Ryan Hurst via dev-security-policy < > > > dev-security-policy@lists.mozilla.org> wrote: > > > > > > > A few problems I see with the proposed text: > > > > > > > > - What is sufficient? I would go with a definition tied to the > > > > effective strength of the keys it protects; in other words, you > > > > should protect a 2048bit RSA key with something that offers > > > > similar properties or that 2048bit key does not live up to its > > > > 2048 bit properties. This is basically the same CSPRNG > > > > conversation but it's worth looking at > > > > > https://clicktime.symantec.com/a/1/MiD2ZQaRtfOOhnoE5EIpI34AP9rvA3o > > > > > INRRu6XdViYU=?d=5Cqt01e3JJ5HJjzKGE6nRW54FeE3IwbVJCyLgL32Lilma6QZm > k > > > > H2jvdL5ebp7STf-GpEiDhzmVlSKWJlJz8rGU- > hyb22kClbCdDKNFH0hcAHEjtrhmva > > > > pCtr5kNgTYlIotEeIpk2tXzkeWzMD- > zxkh7R7mriLhGO5p2EWRejSrwIHrBj4b1wF0 > > > > b_wYIQDNW12oF8hKmnVApkn0sJxGRbcSk1-Pw- > 0cO9oCmj7Yk
Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)
As I was reading this very interesting thread, I kept asking myself "what are we trying to protect". Are we trying to protect a "Private Key" or a "PKCS#12" file? I suppose the consensus of the community, based mainly on compatibility issues, is that we can't avoid the solution of a PKCS#12 file, so we need to figure out how to send this file with reasonable security to the Subscriber. We have two areas of concern: 1. How to prevent an attacker from getting the PKCS#12 file 2. If an attacker obtains the PKCS#12 file, make sure the encryption is reasonable and endurable to practically sustain a decryption attempt that would practically take longer to crack than the lifetime of the Certificate For area 1, the file must be distributed via secure channel. Some recommendations: 1. Web page (protected by https) via authentication of the Subscriber 2. S/MIME encrypted email by using an existing Subscriber valid Certificate 3. Some might also use pgp for S/MIME 4. Registered post, if delivered in a simple USB 5. Registered, or not registered post, if delivered in a FIPS 140-2 Level 3 USB drive 6. ... 7. ... Do we need to expand on this list? What if there are other equally-secure methods that we haven't listed? This definitely doesn't look like a policy text to me. It describes very specific practices/procedures that should be the CA's job to discover and Auditor's to verify, but I also understand that in practice, some CAs haven't demonstrated good judgment on these topics and auditors didn't help either. For area 2, obviously, if an attacker obtains the PKCS#12 file and has infinite time, the key will be decrypted. I believe the discussion resulted in two dominating factors: * The encryption algorithms in the PKCS#12 file * The password quality For the encryption algorithms, I recommend that we defer to other organization's guidelines, such as SOGIS, NIST or ETSI, that have extensively studied the "strength" of encryption algorithms. I can't tell if this community or Mozilla is confident enough to choose a specific set of "approved" encryption algorithms. For the password quality, we should follow the definition of a "Random Value" as described in the Baseline Requirements *"Random Value*: A value specified by a CA to the Applicant that exhibits at least 112 bits of entropy." And yes, I would also recommend the usage of a CSPRNG. With that said, even if this process (performed by the CA) produces complex passwords that contain special characters and (in an unlikely event) might take 20 minutes to type, it is still going to be used "just once" and the Subscriber can then do whatever he/she wants with it. The Subscriber can change the passphrase to "1234" for all we care. As far as the CA is concerned, the main job is done. The file has been encrypted with a reasonably secure algorithm and protected with a reasonably secure passphrase. Of course the passphrase will be delivered separately! Finally, I would like to ask if the community thinks that it's reasonable to put all of our protection efforts on area 2. If we raise the bar on area 2 (the proper protection of the PKCS#12 file), we don't need to worry "too much" about area 1. We could even send a file via plain e-mail because it won't matter if the attacker obtains the file. It is already encrypted securely. I would still recommend both but I also understand the convenience of the Subscribers and the delivery methods for some of these files in types of devices that I am not aware of (IoT, some smart phones, etc). Dimitris. On 4/5/2018 1:01 πμ, Buschart, Rufus via dev-security-policy wrote: Basically I like the new wording: PKCS#12 files [...] SHALL have a password containing at least 112 bits of output from a CSPRNG, [...] But I think there is a practical problem here: Directly using the output of any random number generator ("C" or not) to generate a password will lead to passwords which contain most probably characters that are either not printable or at least not type-able on a 'normal' western style keyboard. Therefore I think we need to reword the password strength section a little bit, maybe like the following: PKCS#12 files [...] SHALL have a 14 character long password consisting of characters, digits and special characters based on output from a CSPRNG, [...] When I originally proposed my wording, I had the serial numbers in my mind (for which directly using the output of a CSPRNG works), but didn't think on the encoding problem. With best regards, Rufus Buschart 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 Office
Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)
Basically I like the new wording: > PKCS#12 files [...] SHALL have a password containing at least 112 bits > of output from a CSPRNG, [...] But I think there is a practical problem here: Directly using the output of any random number generator ("C" or not) to generate a password will lead to passwords which contain most probably characters that are either not printable or at least not type-able on a 'normal' western style keyboard. Therefore I think we need to reword the password strength section a little bit, maybe like the following: > PKCS#12 files [...] SHALL have a 14 character long password consisting > of characters, digits and special characters based on output from a > CSPRNG, [...] When I originally proposed my wording, I had the serial numbers in my mind (for which directly using the output of a CSPRNG works), but didn't think on the encoding problem. With best regards, Rufus Buschart 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 Carl Mehner via dev-security-policy > Gesendet: Mittwoch, 2. Mai 2018 07:45 > An: mozilla-dev-security-pol...@lists.mozilla.org > Betreff: Re: Policy 2.6 Proposal: Add prohibition on CA key generation > to policy > > On Tuesday, May 1, 2018 at 6:40:53 PM UTC-5, Wayne Thayer wrote: > > Ryan - thanks for raising these issues again. I still have concerns > > about getting this specific in the policy, but since we're now > > headed down that road... > > > > On Tue, May 1, 2018 at 7:13 PM, Ryan Hurst via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > > > > A few problems I see with the proposed text: > > > > > > - What is sufficient? I would go with a definition tied to the > > > effective strength of the keys it protects; in other words, you > > > should protect a 2048bit RSA key with something that offers > > > similar properties or that 2048bit key does not live up to its > > > 2048 bit properties. This is basically the same CSPRNG > > > conversation but it's worth looking at https://www.keylength.com/ > > > > > > The latest proposal replaces "sufficient" with "at least 64 bits of > > output from a CSPRNG". We could go back to "sufficient strength for > > the keys it protects", but that also leaves quite a bit of room for > > misinterpretation. > > > > Are there objections to "at least 112 bits of output from a CSPRNG" > > as Tim proposed? > > I'd recommend making a requirement that it be "protected" by at least > as many bits of strength as the key it protects. Not doing so could cause > compliance issues: things like PCI [1] and the NIST [2] recommendations > require this type of protection. > However, like Wayne said, this still leaves room for interpretation, > if mentioning bits is necessary, can we just bump it up to 256 rather than > 112? > > I went back to the word "protect" to rule out the use of 3DES because > bumping up the password past 112 bits doesn't really do much good if the > underlying algorithm maxes out its protective strength at 112. > I realize this will decrease the utility of the p12/pfx files since > none of the adequately protected files would be openable on any > version of Windows. However, the team at Microsoft is well aware of this and > they can prioritize their own backlog (they just don't appear to have been > given the right incentive to do so as of yet). Perhaps we can add a > date-gate.. > > How about: > > PKCS#12 files SHALL be encrypted and signed; or, SHALL have a password > containing at least 112 bits of output from a CSPRNG, and the password > SHALL be transferred using a different channel than the PKCS#12 file. > Beginning January 1, 2020 PKCS#12 files must be protected by at least 256 > bits of output from a CSPRNG. > > This would give people like Microsoft some extra time to update their > implementations to support AES. > > > -Carl > > [1] PCI - DSS v3.2, Section 3.5 > [2] 800-57 Part 1, Section 6.2.1.3 - > https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt > 1r4.pdf ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy __
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://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
AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy
For us at Siemens PKI this wording would work, because we establish a first channel for email encryption to every employee when he receives his corporate smart card / ID card. But I still think the community should have a broad discussion what is acceptable behavior for transmitting S/MIME P12s and what not. For example if the CA sends not the P12-file directly to the subject but a link to download the P12 via HTTPS from a server of the CA, the level of security is practically the same as sending the P12-file directly (in both cases the operator of the mail server can intercept the P12 file easily) but it would be an allowed practice. /Rufus Von: Wayne Thayer [mailto:wtha...@mozilla.com] Gesendet: Freitag, 20. April 2018 22:00 An: Buschart, Rufus (GS IT HR 7 4) Cc: mozilla-dev-security-policy; Wichmann, Markus Peter (GS IT ISEC TE DI IS); Grotz, Florian (GS IT HR 7 4) Betreff: Re: Policy 2.6 Proposal: Add prohibition on CA key generation to policy On Tue, Apr 17, 2018 at 6:10 AM, Buschart, Rufus via dev-security-policy mailto:dev-security-policy@lists.mozilla.org>> wrote: I believe the wording "insecure electronic channels" leaves a lot of space for interpretation. In corporate PKIs for email encryption it is quite common to transfer centrally generated email encryption p12-files to mobile device management systems, email encryption gateways or directly to mobile devices using a wide variety of 'electronic channels'. From the proposed wording it doesn't seem to be clear which of those channels are 'insecure' and which not. Even if not that common, the same applies for email signature p12-files for e.g. email signature on mail gateways or mobile devices. Most of the mobile devices out in the field neither support hardware token, key-pair-generation in the mailer software nor installation of downloaded p12-files (prohibited by app sandboxing). Maybe it would be possible to restrict the new wording to the EKU kp-ServerAuth first and have a detailed discussion about email-encryption and user authentication with more interested parties in the next months? Again, this is not new wording. It's already a requirement: https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Distributing_Generated_Private_Keys_in_PKCS.2312_Files Having said that, could we instead be more specific by replacing "insecure electronic channels" with "unencrypted email"? Limiting the scope of this statement to id-kp-serverAuth is meaningless since we forbid CA key generation for server certificates. - Wayne ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy