Discussion:
Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)
(too old to reply)
Buschart, Rufus via dev-security-policy
2018-05-03 22:01:06 UTC
Permalink
PKCS#12 files [...] SHALL have a password containing at least 112 bits
of output from a CSPRNG, [...]
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:***@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
ozilla.org] Im Auftrag von Carl Mehner via dev-security-policy
Gesendet: Mittwoch, 2. Mai 2018 07:45
Betreff: Re: Policy 2.6 Proposal: Add prohibition on CA key generation
to policy
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 <
- 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..
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
https://lists.mozilla.org/listinfo/dev-security-policy
Dimitris Zacharopoulos via dev-security-policy
2018-05-04 05:22:32 UTC
Permalink
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.
Post by Buschart, Rufus via dev-security-policy
PKCS#12 files [...] SHALL have a password containing at least 112 bits
of output from a CSPRNG, [...]
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
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
ozilla.org] Im Auftrag von Carl Mehner via dev-security-policy
Gesendet: Mittwoch, 2. Mai 2018 07:45
Betreff: Re: Policy 2.6 Proposal: Add prohibition on CA key generation
to policy
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 <
- 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..
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
https://lists.mozilla.org/listinfo/dev-security-policy
_______________________________________________
dev-security-policy mailing list
https://lists.mozilla.org/listinfo/dev-security-policy
Tim Hollebeek via dev-security-policy
2018-05-04 10:10:37 UTC
Permalink
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-
Buschart,
Rufus via dev-security-policy
Sent: Thursday, May 3, 2018 6:01 PM
Subject: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key
generation to policy)
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,
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
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
ozilla.org] Im Auftrag von Carl Mehner via dev-security-policy
Gesendet: Mittwoch, 2. Mai 2018 07:45
Betreff: Re: Policy 2.6 Proposal: Add prohibition on CA key generation
to policy
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 <
- 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-
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
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..
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://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
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
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 via dev-security-policy
2018-05-04 11:22:08 UTC
Permalink
Post by Tim Hollebeek via dev-security-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.
string password = Base32.Encode(CSPRNG.ReadBytes(n));
where n >= 112, we should do.
Maybe you want n = 112 / 8 = 14 bytes.
Post by Tim Hollebeek via dev-security-policy
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 via dev-security-policy
2018-05-04 11:56:28 UTC
Permalink
Post by Kurt Roeckx via dev-security-policy
Maybe you want n = 112 / 8 = 14 bytes.
Doh! Yes.

-Tim
Wayne Thayer via dev-security-policy
2018-05-04 18:58:21 UTC
Permalink
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 via dev-security-policy
2018-05-04 19:59:20 UTC
Permalink
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-
Thayer via dev-security-policy
Sent: Friday, May 4, 2018 2:58 PM
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
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
https://lists.mozilla.org/listinfo/dev-security-policy
Carl Mehner via dev-security-policy
2018-05-04 20:25:18 UTC
Permalink
Hey Doug,
Post by Doug Beattie via dev-security-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
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)
Post by Doug Beattie via dev-security-policy
- 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."
Post by Doug Beattie via dev-security-policy
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 via dev-security-policy
2018-05-04 20:34:28 UTC
Permalink
On Fri, May 4, 2018 at 1:25 PM Carl Mehner via dev-security-policy <
Post by Carl Mehner via dev-security-policy
Hey Doug,
Post by Doug Beattie via dev-security-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..."
Post by Doug Beattie via dev-security-policy
- 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)
Post by Doug Beattie via dev-security-policy
- 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...
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.
Post by Carl Mehner via dev-security-policy
Post by Doug Beattie via dev-security-policy
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.
Post by Carl Mehner via dev-security-policy
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.
Post by Carl Mehner via dev-security-policy
-carl
_______________________________________________
dev-security-policy mailing list
https://lists.mozilla.org/listinfo/dev-security-policy
Ryan Hurst via dev-security-policy
2018-05-04 20:35:20 UTC
Permalink
Post by Doug Beattie via dev-security-policy
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.
Post by Doug Beattie via dev-security-policy
- 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
Post by Doug Beattie via dev-security-policy
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?
Doug Beattie via dev-security-policy
2018-05-07 11:24:09 UTC
Permalink
-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-
Hurst via dev-security-policy
Sent: Friday, May 4, 2018 4:35 PM
Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key
generation to policy)
Post by Doug Beattie via dev-security-policy
First comments on this: "MUST be encrypted and signed; or, MUST have a
password that..."
Post by Doug Beattie via dev-security-policy
- 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,
Post by Doug Beattie via dev-security-policy
- 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.
Post by Doug Beattie via dev-security-policy
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
https://lists.mozilla.org/listinfo/dev-security-policy
Wayne Thayer via dev-security-policy
2018-05-11 16:10:37 UTC
Permalink
Doug,
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
*Sent:* Wednesday, May 9, 2018 11:43 PM
*Cc:* mozilla-dev-security-policy <
*Subject:* Re: FW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition
on CA key generation to policy)
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
Bruce via dev-security-policy
2018-05-14 18:29:06 UTC
Permalink
Post by Wayne Thayer via dev-security-policy
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?
Wayne Thayer via dev-security-policy
2018-05-14 20:44:00 UTC
Permalink
On Mon, May 14, 2018 at 11:29 AM Bruce via dev-security-policy <
Post by Bruce via dev-security-policy
Post by Wayne Thayer via dev-security-policy
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
Post by Wayne Thayer via dev-security-policy
current guidelines published by a recognized standards body. PKCS#12
files
Post by Wayne Thayer via dev-security-policy
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.
Ryan Hurst via dev-security-policy
2018-05-04 20:37:01 UTC
Permalink
Post by Carl Mehner via dev-security-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.
Carl Mehner via dev-security-policy
2018-05-04 20:47:30 UTC
Permalink
Post by Ryan Hurst via dev-security-policy
Post by Carl Mehner via dev-security-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.
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 via dev-security-policy
2018-05-04 21:18:40 UTC
Permalink
Post by Carl Mehner via dev-security-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 :)
Tim Hollebeek via dev-security-policy
2018-05-14 16:52:03 UTC
Permalink
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-
Hurst via dev-security-policy
Sent: Friday, May 4, 2018 5:19 PM
Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key
generation to policy)
Post by Carl Mehner via dev-security-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
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
Doug Beattie via dev-security-policy
2018-05-14 18:50:14 UTC
Permalink
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-
Hollebeek via dev-security-policy
Sent: Monday, May 14, 2018 12:52 PM
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+Ryan
Hurst via dev-security-policy
Sent: Friday, May 4, 2018 5:19 PM
Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on
CA key generation to policy)
Post by Carl Mehner via dev-security-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
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
Wayne Thayer via dev-security-policy
2018-05-14 20:53:44 UTC
Permalink
On Mon, May 14, 2018 at 11:50 AM Doug Beattie via dev-security-policy <
Post by Doug Beattie via dev-security-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
Or the user could generate the key :-)
Post by Doug Beattie via dev-security-policy
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
• 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
Doug Beattie via dev-security-policy
2018-05-15 14:51:06 UTC
Permalink
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:***@mozilla.com]
Sent: Monday, May 14, 2018 4:54 PM
To: Doug Beattie <***@globalsign.com>; mozilla-dev-security-policy <mozilla-dev-security-***@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-security-***@lists.mozilla.org<mailto:dev-security-***@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 via dev-security-policy
2018-05-15 15:51:18 UTC
Permalink
Post by Doug Beattie via dev-security-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.
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.
Post by Doug Beattie via dev-security-policy
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.
Post by Doug Beattie via dev-security-policy
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.
Post by Doug Beattie via dev-security-policy
Doug
*Sent:* Monday, May 14, 2018 4:54 PM
*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 <
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
• 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
Dimitris Zacharopoulos via dev-security-policy
2018-05-15 17:23:08 UTC
Permalink
Post by Wayne Thayer via dev-security-policy
Post by Doug Beattie via dev-security-policy
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 via dev-security-policy
2018-05-15 20:09:53 UTC
Permalink
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
Post by Doug Beattie via dev-security-policy
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 via dev-security-policy
2018-05-16 04:17:33 UTC
Permalink
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-
Thayer via dev-security-policy
Sent: Tuesday, May 15, 2018 4:10 PM
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
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
https://lists.mozilla.org/listinfo/dev-security-policy
Wayne Thayer via dev-security-policy
2018-05-16 04:32:32 UTC
Permalink
Post by Tim Hollebeek via dev-security-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.
This is already a Mozilla requirement [1] - we're just moving it into the
policy document.
Post by Tim Hollebeek via dev-security-policy
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.
Post by Tim Hollebeek via dev-security-policy
-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 via dev-security-policy
2018-05-16 06:23:13 UTC
Permalink
When we debated it last, my predictions were hypothetical.



I wish they had remained hypothetical.



-Tim



From: Wayne Thayer [mailto:***@mozilla.com]
Sent: Wednesday, May 16, 2018 12:33 AM
To: Tim Hollebeek <***@digicert.com>; mozilla-dev-security-policy
<mozilla-dev-security-***@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 <***@digicert.com
<mailto:***@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
Buschart, Rufus via dev-security-policy
2018-06-08 14:32:14 UTC
Permalink
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:***@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
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
Sent: Wednesday, May 16, 2018 12:33 AM
mozilla-dev-security-policy
Subject: 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.
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
Wayne Thayer via dev-security-policy
2018-06-09 21:18:43 UTC
Permalink
Post by Buschart, Rufus via dev-security-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.
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.

Peter Bowen via dev-security-policy
2018-05-16 04:43:18 UTC
Permalink
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
Post by Tim Hollebeek via dev-security-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-
Thayer via dev-security-policy
Sent: Tuesday, May 15, 2018 4:10 PM
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
Post by Doug Beattie via dev-security-policy
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?
Post by Doug Beattie via dev-security-policy
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
https://lists.mozilla.org/listinfo/dev-security-policy
_______________________________________________
dev-security-policy mailing list
https://lists.mozilla.org/listinfo/dev-security-policy
Tim Hollebeek via dev-security-policy
2018-05-16 04:33:33 UTC
Permalink
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-
Zacharopoulos via dev-security-policy
Sent: Tuesday, May 15, 2018 1:23 PM
Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key
generation to policy)
Post by Wayne Thayer via dev-security-policy
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?
Post by Wayne Thayer via dev-security-policy
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
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
Tim Hollebeek via dev-security-policy
2018-05-16 04:27:56 UTC
Permalink
Post by Doug Beattie via dev-security-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.
Post by Doug Beattie via dev-security-policy
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
Jakob Bohm via dev-security-policy
2018-05-14 21:05:17 UTC
Permalink
Post by Wayne Thayer via dev-security-policy
On Mon, May 14, 2018 at 11:50 AM Doug Beattie via dev-security-policy <
Post by Doug Beattie via dev-security-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
Or the user could generate the key :-)
Post by Doug Beattie via dev-security-policy
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
• 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
Jakob Bohm via dev-security-policy
2018-05-05 03:22:39 UTC
Permalink
Post by Wayne Thayer via dev-security-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
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
Loading...