Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

[Buschart, Rufus]

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.b...@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-s...@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-secur...@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-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

[Dimitris Zacharopoulos]

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.

[Tim Hollebeek]

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

> https://clicktime.symantec.com/a/1/MiD2ZQaRtfOOhnoE5EIpI34AP9rvA3o
> > > >
> INRRu6XdViYU=?d=5Cqt01e3JJ5HJjzKGE6nRW54FeE3IwbVJCyLgL32Lilma6QZm
> k
> > > > H2jvdL5ebp7STf-GpEiDhzmVlSKWJlJz8rGU-
> hyb22kClbCdDKNFH0hcAHEjtrhmva
> > > > pCtr5kNgTYlIotEeIpk2tXzkeWzMD-
> zxkh7R7mriLhGO5p2EWRejSrwIHrBj4b1wF0
> > > > b_wYIQDNW12oF8hKmnVApkn0sJxGRbcSk1-Pw-
> 0cO9oCmj7YktgoxEy_ChyJCL0rNR
> > > > VIAGL4FEFLugnwgUwhflFoN1ujWwINVoDV10imsz_uQ-
> rITP6m0ZtOOaUWWDRhh6rd
> > > > G73BizNHiOU8uKepckQXTmYUBYipG4q6HdZ_-
> bmLcZ4HtlteJxoytWRbIKzqf9X7ld
> > > >
> Pxgq1WlnDDzMiQmsQ0cVAf8MZCcYw8WTa6ax_O7cku54_qoiUKm4qq2Mgj2iz
> UKJ78
> > > > paomt7WfLIvU5KNWQeJ9KK-
> SWt8y9aLxh6QXvaobBri_WOyMUZmrh_tMbpRawssbZY
> > > >
> hA9x1BzLG3a6eWSDgd0MAvNrzh2qCrnGXlSkM6wzvQ%3D%3D&u=https%3A%
> 2F%2Fw
> > > > ww.keylength.com%2F

> > https://clicktime.symantec.com/a/1/yOtKtPRlJaGiO5FMMDvh-
> qKgjiBUYZ65OBr
> >
> 7YB5wT7k=?d=5Cqt01e3JJ5HJjzKGE6nRW54FeE3IwbVJCyLgL32Lilma6QZmkH2j
> vdL5e
> > bp7STf-GpEiDhzmVlSKWJlJz8rGU-
> hyb22kClbCdDKNFH0hcAHEjtrhmvapCtr5kNgTYlI
> > otEeIpk2tXzkeWzMD-
> zxkh7R7mriLhGO5p2EWRejSrwIHrBj4b1wF0b_wYIQDNW12oF8hK
> > mnVApkn0sJxGRbcSk1-Pw-
> 0cO9oCmj7YktgoxEy_ChyJCL0rNRVIAGL4FEFLugnwgUwhfl
> > FoN1ujWwINVoDV10imsz_uQ-
> rITP6m0ZtOOaUWWDRhh6rdG73BizNHiOU8uKepckQXTmYU
> > BYipG4q6HdZ_-
> bmLcZ4HtlteJxoytWRbIKzqf9X7ldPxgq1WlnDDzMiQmsQ0cVAf8MZCcY
> >
> w8WTa6ax_O7cku54_qoiUKm4qq2Mgj2izUKJ78paomt7WfLIvU5KNWQeJ9KK-
> SWt8y9aLx
> >
> h6QXvaobBri_WOyMUZmrh_tMbpRawssbZYhA9x1BzLG3a6eWSDgd0MAvNrzh
> 2qCrnGXlSk
> >
> M6wzvQ%3D%3D&u=https%3A%2F%2Fnvlpubs.nist.gov%2Fnistpubs%2FSpecia
> lPubl
> > ications%2FNIST.SP.800-57pt 1r4.pdf

> > _______________________________________________
> > dev-security-policy mailing list
> > dev-secur...@lists.mozilla.org
> >

> https://clicktime.symantec.com/a/1/M0LorXtyz72F0Xke0nsBMZOIWokxRGoxK
> xY
> >
> pHIY6kec=?d=5Cqt01e3JJ5HJjzKGE6nRW54FeE3IwbVJCyLgL32Lilma6QZmkH2jv
> dL5e
> > bp7STf-GpEiDhzmVlSKWJlJz8rGU-
> hyb22kClbCdDKNFH0hcAHEjtrhmvapCtr5kNgTYlI
> > otEeIpk2tXzkeWzMD-
> zxkh7R7mriLhGO5p2EWRejSrwIHrBj4b1wF0b_wYIQDNW12oF8hK
> > mnVApkn0sJxGRbcSk1-Pw-
> 0cO9oCmj7YktgoxEy_ChyJCL0rNRVIAGL4FEFLugnwgUwhfl
> > FoN1ujWwINVoDV10imsz_uQ-
> rITP6m0ZtOOaUWWDRhh6rdG73BizNHiOU8uKepckQXTmYU
> > BYipG4q6HdZ_-
> bmLcZ4HtlteJxoytWRbIKzqf9X7ldPxgq1WlnDDzMiQmsQ0cVAf8MZCcY
> >
> w8WTa6ax_O7cku54_qoiUKm4qq2Mgj2izUKJ78paomt7WfLIvU5KNWQeJ9KK-
> SWt8y9aLx
> >
> h6QXvaobBri_WOyMUZmrh_tMbpRawssbZYhA9x1BzLG3a6eWSDgd0MAvNrzh
> 2qCrnGXlSk
> > M6wzvQ%3D%3D&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-
> securi
> > ty-policy

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org

> https://clicktime.symantec.com/a/1/M0LorXtyz72F0Xke0nsBMZOIWokxRGoxK
> xYpHIY6kec=?d=5Cqt01e3JJ5HJjzKGE6nRW54FeE3IwbVJCyLgL32Lilma6QZmkH2
> jvdL5ebp7STf-GpEiDhzmVlSKWJlJz8rGU-
> hyb22kClbCdDKNFH0hcAHEjtrhmvapCtr5kNgTYlIotEeIpk2tXzkeWzMD-
> zxkh7R7mriLhGO5p2EWRejSrwIHrBj4b1wF0b_wYIQDNW12oF8hKmnVApkn0sJ
> xGRbcSk1-Pw-
> 0cO9oCmj7YktgoxEy_ChyJCL0rNRVIAGL4FEFLugnwgUwhflFoN1ujWwINVoDV10
> imsz_uQ-
> rITP6m0ZtOOaUWWDRhh6rdG73BizNHiOU8uKepckQXTmYUBYipG4q6HdZ_-
> bmLcZ4HtlteJxoytWRbIKzqf9X7ldPxgq1WlnDDzMiQmsQ0cVAf8MZCcYw8WTa6
> ax_O7cku54_qoiUKm4qq2Mgj2izUKJ78paomt7WfLIvU5KNWQeJ9KK-
> SWt8y9aLxh6QXvaobBri_WOyMUZmrh_tMbpRawssbZYhA9x1BzLG3a6eWSDgd
> 0MAvNrzh2qCrnGXlSkM6wzvQ%3D%3D&u=https%3A%2F%2Flists.mozilla.org%
> 2Flistinfo%2Fdev-security-policy

[Kurt Roeckx]

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

[Tim Hollebeek]

> Maybe you want n = 112 / 8 = 14 bytes.

Doh! Yes.

-Tim

[Wayne Thayer]

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

[Doug Beattie]

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=globals...@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 <mozilla-dev-s...@lists.mozilla.org>
> 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-secur...@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-security-policy

[Carl Mehner]

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

[Wayne Thayer]

On Fri, May 4, 2018 at 1:25 PM Carl Mehner via dev-security-policy <
dev-secur...@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

[Ryan Hurst]

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?

[Ryan Hurst]

>
> 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.

[Carl Mehner]

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)

[Ryan Hurst]

> 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 :)

[Jakob Bohm]

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

[Doug Beattie]

> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globals...@lists.mozilla.org] On Behalf Of Ryan
> Hurst via dev-security-policy
> Sent: Friday, May 4, 2018 4:35 PM
> To: mozilla-dev-s...@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.

[Wayne Thayer]

Doug,

On Mon, May 7, 2018 at 11:24 AM Doug Beattie via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> > -----Original Message-----
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+doug.beattie=globals...@lists.mozilla.org] On Behalf Of Ryan
> > Hurst via dev-security-policy
> > Sent: Friday, May 4, 2018 4:35 PM
> > To: mozilla-dev-s...@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?
> >

[Doug Beattie]

>From: Wayne Thayer [mailto:wth...@mozilla.com]
>Sent: Monday, May 7, 2018 8:43 PM
>To: Doug Beattie <doug.b...@globalsign.com>
>Cc: Ryan Hurst <ryan....@gmail.com>; mozilla-dev-security-policy <mozilla-dev-security->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:globals...@lists.mozilla.org] On Behalf Of Ryan
>> Hurst via dev-security-policy
>> Sent: Friday, May 4, 2018 4:35 PM
>> To: mailto:mozilla-dev-s...@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?
>>

[Wayne Thayer]

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

[Doug Beattie]

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:wth...@mozilla.com]
Sent: Wednesday, May 9, 2018 11:43 PM
To: Doug Beattie <doug.b...@globalsign.com>

Cc: mozilla-dev-security-policy <mozilla-dev-s...@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.

[Wayne Thayer]

Doug,

On Thu, May 10, 2018 at 10:57 AM Doug Beattie <doug.b...@globalsign.com>
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:wth...@mozilla.com]
> *Sent:* Wednesday, May 9, 2018 11:43 PM
> *To:* Doug Beattie <doug.b...@globalsign.com>
> *Cc:* mozilla-dev-security-policy <
> mozilla-dev-s...@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.
>
>
>

[Tim Hollebeek]

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=digice...@lists.mozilla.org] On Behalf Of Ryan
> Hurst via dev-security-policy
> Sent: Friday, May 4, 2018 5:19 PM
> To: mozilla-dev-s...@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-secur...@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

[Bruce]

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?

[Doug Beattie]

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=globals...@lists.mozilla.org] On Behalf Of Tim
> Hollebeek via dev-security-policy
> Sent: Monday, May 14, 2018 12:52 PM
> To: Ryan Hurst <ryan....@gmail.com>; 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=digice...@lists.mozilla.org] On Behalf Of
> > bounces+Ryan
> > Hurst via dev-security-policy
> > Sent: Friday, May 4, 2018 5:19 PM
> > To: mozilla-dev-s...@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-secur...@lists.mozilla.org

[Wayne Thayer]

On Mon, May 14, 2018 at 11:29 AM Bruce via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On Wednesday, May 9, 2018 at 11:42:56 PM UTC-4, Wayne Thayer wrote:

> 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.

[Wayne Thayer]

On Mon, May 14, 2018 at 11:50 AM Doug Beattie via dev-security-policy <
dev-secur...@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 :-)

> 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
>
>
>

[Jakob Bohm]

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.

[Doug Beattie]

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:wth...@mozilla.com]

Sent: Monday, May 14, 2018 4:54 PM
To: Doug Beattie <doug.b...@globalsign.com>; mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org>
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-secur...@lists.mozilla.org<mailto:dev-secur...@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

[Wayne Thayer]

On Tue, May 15, 2018 at 7:51 AM Doug Beattie <doug.b...@globalsign.com>
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:wth...@mozilla.com]

> *Sent:* Monday, May 14, 2018 4:54 PM
> *To:* Doug Beattie <doug.b...@globalsign.com>;
> mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org
> >
> *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 <

> 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

[Dimitris Zacharopoulos]

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.

[Wayne Thayer]

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 <ji...@it.auth.gr>
wrote:

[Tim Hollebeek]

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=digice...@lists.mozilla.org] On Behalf Of Wayne
> Thayer via dev-security-policy
> Sent: Tuesday, May 15, 2018 4:10 PM
> To: Dimitris Zacharopoulos <ji...@it.auth.gr>
> Cc: mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org>
> 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 <ji...@it.auth.gr>
> 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.
> >

[Tim Hollebeek]

> 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

[Wayne Thayer]

On Tue, May 15, 2018 at 9:17 PM Tim Hollebeek <tim.ho...@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

[Tim Hollebeek]

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=digice...@lists.mozilla.org] On Behalf Of Dimitris
> Zacharopoulos via dev-security-policy
> Sent: Tuesday, May 15, 2018 1:23 PM
> To: Wayne Thayer <wth...@mozilla.com>
> Cc: mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org>
> 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-secur...@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

[Peter Bowen]

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
<dev-secur...@lists.mozilla.org> 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=digice...@lists.mozilla.org] On Behalf Of Wayne
>> Thayer via dev-security-policy
>> Sent: Tuesday, May 15, 2018 4:10 PM
>> To: Dimitris Zacharopoulos <ji...@it.auth.gr>

>> Cc: mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org>
>> 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 <ji...@it.auth.gr>
>> 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-secur...@lists.mozilla.org

>> https://lists.mozilla.org/listinfo/dev-security-policy

>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Tim Hollebeek]

When we debated it last, my predictions were hypothetical.



I wish they had remained hypothetical.



-Tim

From: Wayne Thayer [mailto:wth...@mozilla.com]

Sent: Wednesday, May 16, 2018 12:33 AM
To: Tim Hollebeek <tim.ho...@digicert.com>; mozilla-dev-security-policy
<mozilla-dev-s...@lists.mozilla.org>
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 <tim.ho...@digicert.com
<mailto:tim.ho...@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.

>

[Buschart, Rufus]

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.b...@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

[Wayne Thayer]

On Fri, Jun 8, 2018 at 2:32 PM Buschart, Rufus <rufus.b...@siemens.com>
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.