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

[Wayne Thayer via dev-security-policy]

On Fri, Jun 8, 2018 at 2:32 PM Buschart, Rufus 
wrote:

> Did we somehow came to a conclusion / agreed wording here? I'm not sure if
> I missed something, but the last email I've received in regards to this
> issue is from mid of May and the last change in
> https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md
> dates to beginning of March. I don't want to make artificial pressure here
> but want to be sure I don't miss something important.
>
> I went ahead with my most recent proposal from 15-March and removed all of
the PKCS#12 language from the proposal:
https://github.com/mozilla/pkipolicy/commit/c56e0fed3d9ada3bba2f466b3ba638dc652b913b

These changes are in the 2.6 branch on GitHub.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

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


With best regards,
Rufus Buschart

Siemens AG
Information Technology
Human Resources
PKI / Trustcenter
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.twitter.com/siemens

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive 
Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, 
Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; 
Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; 
WEEE-Reg.-No. DE 23691322

> -Ursprüngliche Nachricht-
> Von: dev-security-policy
> [mailto:dev-security-policy-bounces+rufus.buschart=siemens.com@lists.m
> ozilla.org] Im Auftrag von Tim Hollebeek via dev-security-policy
> Gesendet: Mittwoch, 16. Mai 2018 08:23
> An: Wayne Thayer; mozilla-dev-security-policy
> Betreff: RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on 
> CA key generation to policy)
> 
> When we debated it last, my predictions were hypothetical.
> 
> 
> 
> I wish they had remained hypothetical.
> 
> 
> 
> -Tim
> 
> 
> 
> From: Wayne Thayer [mailto:wtha...@mozilla.com]
> Sent: Wednesday, May 16, 2018 12:33 AM
> To: Tim Hollebeek ; 
> mozilla-dev-security-policy 
> 
> Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on 
> CA key generation to policy)
> 
> 
> 
> On Tue, May 15, 2018 at 9:17 PM Tim Hollebeek  <mailto:tim.holleb...@digicert.com> > wrote:
> 
> My only objection is that this will cause key generation to shift to 
> partners and affiliates, who will almost certainly do an even worse job.
> 
> >
> 
> This is already a Mozilla requirement [1] - we're just moving it into the 
> policy document.
> 
> >
> 
> If you want to ban key generation by anyone but the end entity, ban key 
> generation by anyone but the end entity.
> 
> >
> 
> We've already debated this [2] and didn't come to that conclusion.
> 
> >
> 
> -Tim
> 
> 
> 
> [1]
> https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Distrib
> uting_Generated_Private_Keys_in_PKCS.2312_Files
> 
> [2]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/MRd8gDwGGA
> 4/AC4xgZ9CBgAJ
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Tim Hollebeek via dev-security-policy]

When we debated it last, my predictions were hypothetical.



I wish they had remained hypothetical.



-Tim



From: Wayne Thayer [mailto:wtha...@mozilla.com]
Sent: Wednesday, May 16, 2018 12:33 AM
To: Tim Hollebeek <tim.holleb...@digicert.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)



On Tue, May 15, 2018 at 9:17 PM Tim Hollebeek <tim.holleb...@digicert.com 
<mailto:tim.holleb...@digicert.com> > wrote:

My only objection is that this will cause key generation to shift to partners 
and
affiliates, who will almost certainly do an even worse job.

>

This is already a Mozilla requirement [1] - we're just moving it into the 
policy document.

>

If you want to ban key generation by anyone but the end entity, ban key
generation by anyone but the end entity.

>

We've already debated this [2] and didn't come to that conclusion.

>

-Tim



[1] 
https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Distributing_Generated_Private_Keys_in_PKCS.2312_Files

[2] 
https://groups.google.com/d/msg/mozilla.dev.security.policy/MRd8gDwGGA4/AC4xgZ9CBgAJ



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Peter Bowen via dev-security-policy]

I don't think that is true.  Remember for OV/IV/EV certificates, the
Subscriber is the natural person or Legal Entity identified in the
certificate Subject.  If the Subscriber is using the certificate on a
CDN, it is probably better to have the CDN generate the key rather
than the Subscriber.  The key is never being passed around, in PKCS#12
format or otherwise, even though the Subscriber isn't generating the
key.

On Tue, May 15, 2018 at 9:17 PM, Tim Hollebeek via dev-security-policy
<dev-security-policy@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=digicert@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-security-pol...@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-security-policy@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Wayne Thayer via dev-security-policy]

On Tue, May 15, 2018 at 9:17 PM Tim Hollebeek 
wrote:

> My only objection is that this will cause key generation to shift to
> partners and
> affiliates, who will almost certainly do an even worse job.
>
> >
This is already a Mozilla requirement [1] - we're just moving it into the
policy document.
>

> If you want to ban key generation by anyone but the end entity, ban key
> generation by anyone but the end entity.
>
> >
We've already debated this [2] and didn't come to that conclusion.
>

> -Tim
>

[1]
https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Distributing_Generated_Private_Keys_in_PKCS.2312_Files
[2]
https://groups.google.com/d/msg/mozilla.dev.security.policy/MRd8gDwGGA4/AC4xgZ9CBgAJ
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Tim Hollebeek 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.

> 2) Trying to compute the entropy of a user generated password is  nearly
> impossible.  According to NIST Special Publication 800-63, a good 20 character
> password will have just 48 bits of entropy, and characters after that only 
> add 1
> bite of entropy each.  User stink at generating Entropy (right Tim?)

Yes, users struggle to generate a single bit of entropy per character.  This is 
why
users should not generate keys or passwords.

An encoded CSPRNG can hit 5-6 bits of entropy per character, so 20 is a pretty 
good number for password lengths.  Copy/paste solves most of the usability 
issues.

There are some subtleties that require some care, but the general gist is right.

-Tim



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[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-
> bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Wayne
> Thayer via dev-security-policy
> Sent: Tuesday, May 15, 2018 4:10 PM
> To: Dimitris Zacharopoulos <ji...@it.auth.gr>
> Cc: 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)
> 
> 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-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Wayne Thayer via dev-security-policy]

I'm coming to the conclusion that this discussion is about "security
theater"[1]. As long as we allow CAs to generate S/MIME key pairs, there
are gaping holes in the PKCS#12 requirements, the most obvious being that a
CA can just transfer the private key to the user in pem format! Are there
any objections to dropping the PKCS#12 requirements altogether and just
forbidding key generation for TLS certificates as follows?

CAs MUST NOT generate the key pairs for end-entity certificates that have
an EKU extension containing the KeyPurposeIds id-kp-serverAuth or
anyExtendedKeyUsage.

- Wayne

[1] https://en.wikipedia.org/wiki/Security_theater

On Tue, May 15, 2018 at 10:23 AM Dimitris Zacharopoulos 
wrote:

>
>
> On 15/5/2018 6:51 μμ, Wayne Thayer via dev-security-policy wrote:
>
> Did you consider any changes based on Jakob’s comments?  If the PKCS#12 is
> distributed via secure channels, how strong does the password need to be?
>
>
>
>
>
> I think this depends on our threat model, which to be fair is not something
> we've defined. If we're only concerned with protecting the delivery of the
> PKCS#12 file to the user, then this makes sense. If we're also concerned
> with protection of the file while in possession of the user, then a strong
> password makes sense regardless of the delivery mechanism.
>
>
> I think once the key material is securely delivered to the user, it is no
> longer under the CA's control and we shouldn't assume that it is. The user
> might change the passphrase of the PKCS#12 file to whatever, or store the
> private key without any encryption.
>
>
> Dimitris.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Dimitris Zacharopoulos via dev-security-policy]

On 15/5/2018 6:51 μμ, Wayne Thayer via dev-security-policy wrote:

Did you consider any changes based on Jakob’s comments?  If the PKCS#12 is
distributed via secure channels, how strong does the password need to be?





I think this depends on our threat model, which to be fair is not something
we've defined. If we're only concerned with protecting the delivery of the
PKCS#12 file to the user, then this makes sense. If we're also concerned
with protection of the file while in possession of the user, then a strong
password makes sense regardless of the delivery mechanism.


I think once the key material is securely delivered to the user, it is 
no longer under the CA's control and we shouldn't assume that it is. The 
user might change the passphrase of the PKCS#12 file to whatever, or 
store the private key without any encryption.



Dimitris.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Wayne Thayer via dev-security-policy]

On Tue, May 15, 2018 at 7:51 AM Doug Beattie <doug.beat...@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:wtha...@mozilla.com]
> *Sent:* Monday, May 14, 2018 4:54 PM
> *To:* Doug Beattie <doug.beat...@globalsign.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)
>
>
>
> On Mon, May 14, 2018 at 11:50 AM Doug Beattie via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>
> I hope some other CAs weigh in in this: Robin, Bruce, Jeremy, Daymion,
> Dean???
> - We can’t permit user generated passwords (at least that is Tim's
> proposal, Wayne may not agree yet but he will when he reads this email)
> - We can’t distribute both the password and PKCS#12 over the same channel,
> even if it's a secure channel like HTTPS
>
> We have 2 choices for where the password is generated: CA or User
>
> >
>
> Or the user could generate the key :-)
>
> >
>
> 1) If we require CAs to generate the passwords and they can’t distribute
> the necessary information to the end user via the portal over TLS (because
> of the dual channel requirement), then that is a relatively large impact on
> us, and probably anyone else that supports PKCS#12 file formats.  If the
> channel is secure, do you need to use different channels?
>
>
> 2) Trying to compute the entropy of a user generated password is  nearly
> impossible.  According to NIST Special Publication 800-63, a good 20
> character password will have just 48 bits of entropy, and characters after
> that only add 1 bite of entropy each.  User stink at generating Entropy
> (right Tim?)
>
> NIST Special Publication 800-63 of June 2004 (revision 2) suggested the
> following scheme to roughly estimate the entropy of human-generated
> passwords (Subsequent updates of this publication gave up trying to compute
> entropy for user generated passwords, and when they talk about entropy they
> talk about 20 bits max):
> •   The entropy of the first character is four bits;
> •   The entropy of the next seven characters are two bits per
> character;
> •   The ninth through the twentieth character has 1.5 bits of entropy
> per character;
> •   Characters 21 and above have one bit of entropy per character.
> •   A "bonus" of six bits is added if both upper case letters and
> non-alphabetic characters are used.
> •   A "bonus" of six bits is added for passwords of length 1 through
> 19 characters following an extensive dictionary check to ensure the
> password is not contained within a large dictionary. Passwords of 20
> characters or more do not receive this bonus because it is assumed they are
> pass-phrases consisting of multiple dictionary words.
>
> https://pages.nist.gov/800-63-3/
>
> Some CAs are probably asking the user for a password during the request
> thus there is no need to distribute it later.  But, if the Applicant
> provides the password over HTTPS and then later the CA provides the PKCS#12
> via download link and they obtain it via HTTPS, is that a single channel
> that they were both distributed over?
>
> I still object to not being able to use HTTPS for collection and/or
> distribution of the Password and the PKCS#12.  I also believe 112 bits of
> entropy is way too much for user generated password (assu

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

[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.  I hope there is a sufficiently long time for CAs to 
change their processes and APIs and to roll out updated training and 
documentation to their customers (for this unplanned change).

Did you consider any changes based on Jakob’s comments?  If the PKCS#12 is 
distributed via secure channels, how strong does the password need to be?

Doug



From: Wayne Thayer [mailto:wtha...@mozilla.com]
Sent: Monday, May 14, 2018 4:54 PM
To: Doug Beattie <doug.beat...@globalsign.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)

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

I hope some other CAs weigh in in this: Robin, Bruce, Jeremy, Daymion, Dean???
- We can’t permit user generated passwords (at least that is Tim's proposal, 
Wayne may not agree yet but he will when he reads this email)
- We can’t distribute both the password and PKCS#12 over the same channel, even 
if it's a secure channel like HTTPS

We have 2 choices for where the password is generated: CA or User
>
Or the user could generate the key :-)
>
1) If we require CAs to generate the passwords and they can’t distribute the 
necessary information to the end user via the portal over TLS (because of the 
dual channel requirement), then that is a relatively large impact on us, and 
probably anyone else that supports PKCS#12 file formats.  If the channel is 
secure, do you need to use different channels?


2) Trying to compute the entropy of a user generated password is  nearly 
impossible.  According to NIST Special Publication 800-63, a good 20 character 
password will have just 48 bits of entropy, and characters after that only add 
1 bite of entropy each.  User stink at generating Entropy (right Tim?)

NIST Special Publication 800-63 of June 2004 (revision 2) suggested the 
following scheme to roughly estimate the entropy of human-generated passwords 
(Subsequent updates of this publication gave up trying to compute entropy for 
user generated passwords, and when they talk about entropy they talk about 20 
bits max):
•   The entropy of the first character is four bits;
•   The entropy of the next seven characters are two bits per character;
•   The ninth through the twentieth character has 1.5 bits of entropy per 
character;
•   Characters 21 and above have one bit of entropy per character.
•   A "bonus" of six bits is added if both upper case letters and 
non-alphabetic characters are used.
•   A "bonus" of six bits is added for passwords of length 1 through 19 
characters following an extensive dictionary check to ensure the password is 
not contained within a large dictionary. Passwords of 20 characters or more do 
not receive this bonus because it is assumed they are pass-phrases consisting 
of multiple dictionary words.

https://pages.nist.gov/800-63-3/

Some CAs are probably asking the user for a password during the request thus 
there is no need to distribute it later.  But, if the Applicant provides the 
password over HTTPS and then later the CA provides the PKCS#12 via download 
link and they obtain it via HTTPS, is that a single channel that they were both 
distributed over?

I still object to not being able to use HTTPS for collection and/or 
distribution of the Password and the PKCS#12.  I also believe 112 bits of 
entropy is way too much for user generated password (assuming we want to 
continue supporting that option).
Perhaps the following language is a workable solution to the first objection?

PKCS#12 files must employ an encryption key and algorithm that is sufficiently 
strong to protect the key pair for its useful life based on current guidelines 
published by a recognized standards body. PKCS#12 files MUST be encrypted and 
signed; or, MUST have a password that exhibits at least 112 bits of entropy, 
and the password MUST be transmitted via a secure channel.

I really don't seem a benefit to user generation of these passwords - either 
they are weak and memorable, or sufficiently complicated that there's little 
value in being able to choose it.

Doug

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jakob Bohm via dev-security-policy]

On 14/05/2018 22:53, Wayne Thayer wrote:

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



I hope some other CAs weigh in in this: Robin, Bruce, Jeremy, Daymion,
Dean???
- We can’t permit user generated passwords (at least that is Tim's
proposal, Wayne may not agree yet but he will when he reads this email)
- We can’t distribute both the password and PKCS#12 over the same channel,
even if it's a secure channel like HTTPS

We have 2 choices for where the password is generated: CA or User




Or the user could generate the key :-)





1) If we require CAs to generate the passwords and they can’t distribute
the necessary information to the end user via the portal over TLS (because
of the dual channel requirement), then that is a relatively large impact on
us, and probably anyone else that supports PKCS#12 file formats.  If the
channel is secure, do you need to use different channels?


2) Trying to compute the entropy of a user generated password is  nearly
impossible.  According to NIST Special Publication 800-63, a good 20
character password will have just 48 bits of entropy, and characters after
that only add 1 bite of entropy each.  User stink at generating Entropy
(right Tim?)

NIST Special Publication 800-63 of June 2004 (revision 2) suggested the
following scheme to roughly estimate the entropy of human-generated
passwords (Subsequent updates of this publication gave up trying to compute
entropy for user generated passwords, and when they talk about entropy they
talk about 20 bits max):
•   The entropy of the first character is four bits;
•   The entropy of the next seven characters are two bits per
character;
•   The ninth through the twentieth character has 1.5 bits of entropy
per character;
•   Characters 21 and above have one bit of entropy per character.
•   A "bonus" of six bits is added if both upper case letters and
non-alphabetic characters are used.
•   A "bonus" of six bits is added for passwords of length 1 through
19 characters following an extensive dictionary check to ensure the
password is not contained within a large dictionary. Passwords of 20
characters or more do not receive this bonus because it is assumed they are
pass-phrases consisting of multiple dictionary words.

https://pages.nist.gov/800-63-3/

Some CAs are probably asking the user for a password during the request
thus there is no need to distribute it later.  But, if the Applicant
provides the password over HTTPS and then later the CA provides the PKCS#12
via download link and they obtain it via HTTPS, is that a single channel
that they were both distributed over?

I still object to not being able to use HTTPS for collection and/or
distribution of the Password and the PKCS#12.  I also believe 112 bits of
entropy is way too much for user generated password (assuming we want to
continue supporting that option).

Perhaps the following language is a workable solution to the first

objection?

PKCS#12 files must employ an encryption key and algorithm that is
sufficiently strong to protect the key pair for its useful life based on
current guidelines published by a recognized standards body. PKCS#12 files
MUST be encrypted and signed; or, MUST have a password that exhibits at
least 112 bits of entropy, and the password MUST be transmitted via a
secure channel.

I really don't seem a benefit to user generation of these passwords -
either they are weak and memorable, or sufficiently complicated that
there's little value in being able to choose it.



Maybe reconsider the idea of extending the PKCS#12 key length rules from 
insecure to secure channels.


In other words, if the channel itself is sufficiently secure to allow
distribution of the key in a format with no encryption of its own, then
there maybe shouldn't be additional requirements for the PKCS#12 file.

Also consider the issue of key generation for individual users by
a constrained SubCAs belonging to an organization.  Here the private key
generation and protection may be handled by the organization internal
security and encryption channels, that bear little resemblance to the
3rd party CA scenario.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Wayne Thayer via dev-security-policy]

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

>
> I hope some other CAs weigh in in this: Robin, Bruce, Jeremy, Daymion,
> Dean???
> - We can’t permit user generated passwords (at least that is Tim's
> proposal, Wayne may not agree yet but he will when he reads this email)
> - We can’t distribute both the password and PKCS#12 over the same channel,
> even if it's a secure channel like HTTPS
>
> We have 2 choices for where the password is generated: CA or User
>
> >
Or the user could generate the key :-)
>

> 1) If we require CAs to generate the passwords and they can’t distribute
> the necessary information to the end user via the portal over TLS (because
> of the dual channel requirement), then that is a relatively large impact on
> us, and probably anyone else that supports PKCS#12 file formats.  If the
> channel is secure, do you need to use different channels?
>
>
> 2) Trying to compute the entropy of a user generated password is  nearly
> impossible.  According to NIST Special Publication 800-63, a good 20
> character password will have just 48 bits of entropy, and characters after
> that only add 1 bite of entropy each.  User stink at generating Entropy
> (right Tim?)
>
> NIST Special Publication 800-63 of June 2004 (revision 2) suggested the
> following scheme to roughly estimate the entropy of human-generated
> passwords (Subsequent updates of this publication gave up trying to compute
> entropy for user generated passwords, and when they talk about entropy they
> talk about 20 bits max):
> •   The entropy of the first character is four bits;
> •   The entropy of the next seven characters are two bits per
> character;
> •   The ninth through the twentieth character has 1.5 bits of entropy
> per character;
> •   Characters 21 and above have one bit of entropy per character.
> •   A "bonus" of six bits is added if both upper case letters and
> non-alphabetic characters are used.
> •   A "bonus" of six bits is added for passwords of length 1 through
> 19 characters following an extensive dictionary check to ensure the
> password is not contained within a large dictionary. Passwords of 20
> characters or more do not receive this bonus because it is assumed they are
> pass-phrases consisting of multiple dictionary words.
>
> https://pages.nist.gov/800-63-3/
>
> Some CAs are probably asking the user for a password during the request
> thus there is no need to distribute it later.  But, if the Applicant
> provides the password over HTTPS and then later the CA provides the PKCS#12
> via download link and they obtain it via HTTPS, is that a single channel
> that they were both distributed over?
>
> I still object to not being able to use HTTPS for collection and/or
> distribution of the Password and the PKCS#12.  I also believe 112 bits of
> entropy is way too much for user generated password (assuming we want to
> continue supporting that option).
>
> Perhaps the following language is a workable solution to the first
objection?

PKCS#12 files must employ an encryption key and algorithm that is
sufficiently strong to protect the key pair for its useful life based on
current guidelines published by a recognized standards body. PKCS#12 files
MUST be encrypted and signed; or, MUST have a password that exhibits at
least 112 bits of entropy, and the password MUST be transmitted via a
secure channel.

I really don't seem a benefit to user generation of these passwords -
either they are weak and memorable, or sufficiently complicated that
there's little value in being able to choose it.

Doug
>
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Wayne Thayer via dev-security-policy]

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

> On Wednesday, May 9, 2018 at 11:42:56 PM UTC-4, Wayne Thayer wrote:
> > I think we have settled on the following resolution to this issue:
> >
> > Add the following to section 5.2 (Forbidden and Required Practices):
> >
> > CAs MUST NOT generate the key pairs for end-entity certificates that have
> > > an EKU extension containing the KeyPurposeIds id-kp-serverAuth or
> > > anyExtendedKeyUsage.
> > >
> > > PKCS#12 files must employ an encryption key and algorithm that is
> > > sufficiently strong to protect the key pair for its useful life based
> on
> > > current guidelines published by a recognized standards body. PKCS#12
> files
> > > MUST be encrypted and signed; or, MUST have a password that exhibits at
> > > least 112 bits of entropy, and the password MUST be transferred using a
> > > different channel than the PKCS#12 file.
> > >
> >
> > Unless there is further discussion, I will include this language in the
> > final version of the policy.
> >
> > - Wayne
>
> In one use case, the Subscriber can create their own password to start the
> enrollment process for the S/MIME certificate. The P12 is created,
> encrypted and sent to the Subscriber to be decrypted using the password. I
> think that asking the Subscriber to create a password with 112-bits entropy
> may create a very long password (over 20 characters). I think that this
> will take much longer than the life of the certificate (or its user) to
> crack. This password may also be recorded improperly or recorded on the
> same device as the key will reside. Could we consider reducing the size of
> the password?
>
> Remember that this only applies when the CA generates the key pair. If the
CA must for some reason do that, then it's reasonable to expect the CA to
secure it with a strong password.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[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

1) If we require CAs to generate the passwords and they can’t distribute the 
necessary information to the end user via the portal over TLS (because of the 
dual channel requirement), then that is a relatively large impact on us, and 
probably anyone else that supports PKCS#12 file formats.  If the channel is 
secure, do you need to use different channels? 


2) Trying to compute the entropy of a user generated password is  nearly 
impossible.  According to NIST Special Publication 800-63, a good 20 character 
password will have just 48 bits of entropy, and characters after that only add 
1 bite of entropy each.  User stink at generating Entropy (right Tim?) 

NIST Special Publication 800-63 of June 2004 (revision 2) suggested the 
following scheme to roughly estimate the entropy of human-generated passwords 
(Subsequent updates of this publication gave up trying to compute entropy for 
user generated passwords, and when they talk about entropy they talk about 20 
bits max):
•   The entropy of the first character is four bits;
•   The entropy of the next seven characters are two bits per character;
•   The ninth through the twentieth character has 1.5 bits of entropy per 
character;
•   Characters 21 and above have one bit of entropy per character.
•   A "bonus" of six bits is added if both upper case letters and 
non-alphabetic characters are used.
•   A "bonus" of six bits is added for passwords of length 1 through 19 
characters following an extensive dictionary check to ensure the password is 
not contained within a large dictionary. Passwords of 20 characters or more do 
not receive this bonus because it is assumed they are pass-phrases consisting 
of multiple dictionary words.

https://pages.nist.gov/800-63-3/ 

Some CAs are probably asking the user for a password during the request thus 
there is no need to distribute it later.  But, if the Applicant provides the 
password over HTTPS and then later the CA provides the PKCS#12 via download 
link and they obtain it via HTTPS, is that a single channel that they were both 
distributed over? 

I still object to not being able to use HTTPS for collection and/or 
distribution of the Password and the PKCS#12.  I also believe 112 bits of 
entropy is way too much for user generated password (assuming we want to 
continue supporting that option).

Doug

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of Tim
> Hollebeek via dev-security-policy
> Sent: Monday, May 14, 2018 12:52 PM
> To: Ryan Hurst <ryan.hu...@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=digicert@lists.mozilla.org] On Behalf Of
> > bounces+Ryan
> > Hurst via dev-security-policy
> > Sent: Friday, May 4, 2018 5:19 PM
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on
> > CA key generation to policy)
> >
> >
> > > True, but CAs can put technical constraints on that to limit the
> > > acceptable
> > passwords to a certain strength. (hopefully with a better
> > strength-testing algorithm than the example Tim gave earlier)
> >
> > Tim is the best of us -- this is hard to do well :)
> >
> > ___
> >

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

[Bruce via dev-security-policy]

On Wednesday, May 9, 2018 at 11:42:56 PM UTC-4, Wayne Thayer wrote:
> I think we have settled on the following resolution to this issue:
> 
> Add the following to section 5.2 (Forbidden and Required Practices):
> 
> CAs MUST NOT generate the key pairs for end-entity certificates that have
> > an EKU extension containing the KeyPurposeIds id-kp-serverAuth or
> > anyExtendedKeyUsage.
> >
> > PKCS#12 files must employ an encryption key and algorithm that is
> > sufficiently strong to protect the key pair for its useful life based on
> > current guidelines published by a recognized standards body. PKCS#12 files
> > MUST be encrypted and signed; or, MUST have a password that exhibits at
> > least 112 bits of entropy, and the password MUST be transferred using a
> > different channel than the PKCS#12 file.
> >
> 
> Unless there is further discussion, I will include this language in the
> final version of the policy.
> 
> - Wayne

In one use case, the Subscriber can create their own password to start the 
enrollment process for the S/MIME certificate. The P12 is created, encrypted 
and sent to the Subscriber to be decrypted using the password. I think that 
asking the Subscriber to create a password with 112-bits entropy may create a 
very long password (over 20 characters). I think that this will take much 
longer than the life of the certificate (or its user) to crack. This password 
may also be recorded improperly or recorded on the same device as the key will 
reside. Could we consider reducing the size of the password?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Tim Hollebeek via dev-security-policy]

For the record, I posted someone else's strength testing algorithm, and pointed
out that it was bad   I personally don't think building strength testing 
algorithms 
is hopeless, and I think good ones are very useful.  I tend to agree with the 
current 
NIST recommendation, which is to primarily only consider length, along with 
things 
like history, dictionary words, and reuse.

But in this case, the public is at risk if the key is compromised, so I don't 
trust a 
password chosen by an end user, no matter what strength function it may or may 
not pass.

Some form of random password of sufficient length, with the randomness coming
from a CSPRNG, encoded into a more user friendly form, is the right answer here.

-Tim

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Ryan
> Hurst via dev-security-policy
> Sent: Friday, May 4, 2018 5:19 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key
> generation to policy)
> 
> 
> > True, but CAs can put technical constraints on that to limit the acceptable
> passwords to a certain strength. (hopefully with a better strength-testing
> algorithm than the example Tim gave earlier)
> 
> Tim is the best of us -- this is hard to do well :)
> 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://clicktime.symantec.com/a/1/B4EQCI-
> M91W3VFdrYnu8NKa6AWUA0Oca9gCvph6YNAo=?d=1AFyDzj7qs0LPt1qH7YZK
> X7VDlKTG3u4_pF-smh1LdxQUjK6Fx2ySSFy5RdxazxX-
> o23v3NFfmxRdpLUwPqiW6yozAgZPzuSbInOcX3x3V3ANyskgECX5k4aeBDO0z1u
> RHJpH-
> Wb5WOBjb0n16kco9wf4jRlCIO7HgEH4pMHjx4H_POUivn493OPB7U9RX8BArU
> 5U87OFuHYndlG0UK-XvQOKqKu6t_3fatFfevp7IT8Jzm4Ze-
> xwk8jgsytRsxvWQ561mB9wFaxsYkiFLZMBHmsNDACgJKZxHouitR-aXhUbxF-
> fKeFXogKbfDCYiYLqHOe5i8KyS8AzFNsUaZTDGJisXeUJbui5n9H3tF5berZe0DuntP
> V7a9yad9-
> haeyu7NspHh92Niu71JNcWZks3gkKolxwuU9vUfZCdfiIIhMHniPOMkCkMl0ooM
> gbRFl0gnAgmiNcKuIizRC9Z35_snt4pKSXAU12MQLeTdYFZMGmKYEDTvkB2L_So
> 3AZHYfUXATSUeQQlo1zSRKZ5Mapw%3D%3D=https%3A%2F%2Flists.mozilla
> .org%2Flistinfo%2Fdev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Wayne Thayer via dev-security-policy]

Doug,

On Thu, May 10, 2018 at 10:57 AM Doug Beattie <doug.beat...@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:wtha...@mozilla.com]
> *Sent:* Wednesday, May 9, 2018 11:43 PM
> *To:* Doug Beattie <doug.beat...@globalsign.com>
> *Cc:* mozilla-dev-security-policy <
> mozilla-dev-security-pol...@lists.mozilla.org>
> *Subject:* Re: FW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition
> on CA key generation to policy)
>
>
>
>
>
> I think we have settled on the following resolution to this issue:
>
>
>
> Add the following to section 5.2 (Forbidden and Required Practices):
>
>
>
> CAs MUST NOT generate the key pairs for end-entity certificates that have
> an EKU extension containing the KeyPurposeIds id-kp-serverAuth or
>
> anyExtendedKeyUsage.
>
>
>
> PKCS#12 files must employ an encryption key and algorithm that is
> sufficiently strong to protect the key pair for its useful life based on
> current guidelines published by a recognized standards body. PKCS#12 files
> MUST be encrypted and signed; or, MUST have a password that exhibits at
> least 112 bits of entropy, and the password MUST be transferred using a
> different channel than the PKCS#12 file.
>
>
>
> Unless there is further discussion, I will include this language in the
> final version of the policy.
>
>
>
> - Wayne
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Doug Beattie via dev-security-policy]

Hi Wayne,

I’m OK with this as long as this permits the password (fully or partially 
generated by the CA) and PKCS#12 file to be picked up by a user over HTTPS (a 
single channel).

Doug


From: Wayne Thayer [mailto:wtha...@mozilla.com]
Sent: Wednesday, May 9, 2018 11:43 PM
To: Doug Beattie <doug.beat...@globalsign.com>
Cc: mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org>
Subject: Re: FW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA 
key generation to policy)


I think we have settled on the following resolution to this issue:

Add the following to section 5.2 (Forbidden and Required Practices):

CAs MUST NOT generate the key pairs for end-entity certificates that have an 
EKU extension containing the KeyPurposeIds id-kp-serverAuth or
anyExtendedKeyUsage.

PKCS#12 files must employ an encryption key and algorithm that is sufficiently 
strong to protect the key pair for its useful life based on current guidelines 
published by a recognized standards body. PKCS#12 files MUST be encrypted and 
signed; or, MUST have a password that exhibits at least 112 bits of entropy, 
and the password MUST be transferred using a different channel than the PKCS#12 
file.

Unless there is further discussion, I will include this language in the final 
version of the policy.

- Wayne
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Wayne Thayer via dev-security-policy]

I think we have settled on the following resolution to this issue:

Add the following to section 5.2 (Forbidden and Required Practices):

CAs MUST NOT generate the key pairs for end-entity certificates that have
> an EKU extension containing the KeyPurposeIds id-kp-serverAuth or
> anyExtendedKeyUsage.
>
> PKCS#12 files must employ an encryption key and algorithm that is
> sufficiently strong to protect the key pair for its useful life based on
> current guidelines published by a recognized standards body. PKCS#12 files
> MUST be encrypted and signed; or, MUST have a password that exhibits at
> least 112 bits of entropy, and the password MUST be transferred using a
> different channel than the PKCS#12 file.
>

Unless there is further discussion, I will include this language in the
final version of the policy.

- Wayne
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Doug Beattie via dev-security-policy]

>From: Wayne Thayer [mailto:wtha...@mozilla.com] 
>Sent: Monday, May 7, 2018 8:43 PM
>To: Doug Beattie <doug.beat...@globalsign.com>
>Cc: Ryan Hurst <ryan.hu...@gmail.com>; mozilla-dev-security-policy 
>pol...@lists.mozilla.org>
>Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key 
>generation to policy)
>
>Doug,
>
>On Mon, May 7, 2018 at 11:24 AM Doug Beattie via dev-security-policy 
><mailto:dev-security->pol...@lists.mozilla.org> wrote: 
>> -Original Message-
>> From: dev-security-policy [mailto:mailto:dev-security-policy-
>> bounces+doug.beattie=mailto:globalsign@lists.mozilla.org] On Behalf Of 
>> Ryan
>> Hurst via dev-security-policy
>> Sent: Friday, May 4, 2018 4:35 PM
>> To: mailto:mozilla-dev-security-pol...@lists.mozilla.org
>> Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key
>> generation to policy)
>> 
>> On Friday, May 4, 2018 at 1:00:03 PM UTC-7, Doug Beattie wrote:
>> > First comments on this: "MUST be encrypted and signed; or, MUST have a
>> password that..."
>> > - Isn't the password the key used for encryption?  I'm not sure if the "or"
>> makes sense since in both cases the password is the key for encryption
>> 
>> There are modes of PKCS#12 that do not use passwords.
>If you're stating that we should include the use of PKCS#12 that don't use 
>passwords and that are 
>encrupted, then we need to define the parameters of the key used for that 
>purpose,
>
>Would it be enough to say that "PKCS#12 files must employ an encryption key 
>and algorithm that is 
>sufficiently strong..." (add "key and")?
Sure, that works for me.

>> > - In general, I don't think PKCS#12 files are signed, so I'd leave that 
>> > out, a
>> signature isn't necessary.  I could be wrong...
>> 
>> They may be, see: http://unmitigatedrisk.com/?p=543
>The requirement seems to imply it must be signed, and I don't think we want 
>that, do we?  I think 
>should remove "or signed" and that will permit them to be signed, but not 
>require it.
>
> That's not hoe I read it. The proposed language provides the option of 
>'encrypted and signed' or 
>protected with a password'. Since your use case is 'protected with a 
>password', there is no requirement 
>for the file to be signed.
OK

>>
>> >
>> > I'd still like to see a modification on the requirement: "password MUST be
>> transferred using a different channel than the PKCS#12 file".  A user should 
>> be
>> able to download the P12 and password via HTTP.  Can we add an exception
>> for that?
>> 
>> Why do you want to allow the use of HTTP?
>Sorry, I meant HTTPS.  
 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Wayne Thayer via dev-security-policy]

Doug,

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

> > -Original Message-
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of Ryan
> > Hurst via dev-security-policy
> > Sent: Friday, May 4, 2018 4:35 PM
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on
> CA key
> > generation to policy)
> >
> > On Friday, May 4, 2018 at 1:00:03 PM UTC-7, Doug Beattie wrote:
> > > First comments on this: "MUST be encrypted and signed; or, MUST have a
> > password that..."
> > > - Isn't the password the key used for encryption?  I'm not sure if the
> "or"
> > makes sense since in both cases the password is the key for encryption
> >
> > There are modes of PKCS#12 that do not use passwords.
> If you're stating that we should include the use of PKCS#12 that don't use
> passwords and that are encrupted, then we need to define the parameters of
> the key used for that purpose,
>
> >
Would it be enough to say that "PKCS#12 files must employ an encryption key
and algorithm that is sufficiently strong..." (add "key and")?
>

> > > - In general, I don't think PKCS#12 files are signed, so I'd leave
> that out, a
> > signature isn't necessary.  I could be wrong...
> >
> > They may be, see: http://unmitigatedrisk.com/?p=543
> The requirement seems to imply it must be signed, and I don't think we
> want that, do we?  I think should remove "or signed" and that will permit
> them to be signed, but not require it.
>
>
 That's not hoe I read it. The proposed language provides the option of
'encrypted and signed' or 'protected with a password'. Since your use case
is 'protected with a password', there is no requirement for the file to be
signed.
>

> > >
> > > I'd still like to see a modification on the requirement: "password
> MUST be
> > transferred using a different channel than the PKCS#12 file".  A user
> should be
> > able to download the P12 and password via HTTP.  Can we add an exception
> > for that?
> >
> > Why do you want to allow the use of HTTP?
> Sorry, I meant HTTPS.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jakob Bohm via dev-security-policy]

On 04/05/2018 20:58, Wayne Thayer wrote:

The optimist in me thinks we might be getting close to resolving this issue
(the last one remaining for the 2.6 policy update). Here is another
proposal that attempts to account for most of the input we've received:

Add the following to section 5.2 (Forbidden and Required Practices):

CAs MUST NOT generate the key pairs for end-entity certificates that have

an EKU extension containing the KeyPurposeIds id-kp-serverAuth or
anyExtendedKeyUsage.

PKCS#12 files must employ an encryption algorithm that is sufficiently
strong to protect the key pair for its useful life based on current
guidelines published by a recognized standards body. PKCS#12 files MUST be
encrypted and signed; or, MUST have a password that exhibits at least 112
bits of entropy, and the password MUST be transferred using a different
channel than the PKCS#12 file.



This isn't perfect. I would appreciate your comments if you have
significant concerns with this proposed policy.

- Wayne



Given the fiasco of at least one major PKCS#12 implementation only
allowing embarrassingly weak encryption, while simultaneously insisting
on not accepting other private key import formats:

Wouldn't it be prudent to allow transport of PKCS#12 files (with weak
compatible encryption) inside a much stronger encrypted container such
as a strongly encrypted S/MIME message or a strongly encrypted TLS
transmission (HTTPS, LDAPS etc.).

The idea being that the weak PKCS#12 encryption is not treated as the
private key protection, but merely as a file format artifact.

I have previously given a (hypothetical) example of a procedure that
relies on tamper-evident physical envelopes rather than cryptography to
protect the private key delivery.  That would be another example of
using a different mechanism than PKCS#12 encryption for turning an
insecure channel into a secure private key delivery mechanism.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ryan Hurst 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
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Carl Mehner via dev-security-policy]

On Friday, May 4, 2018 at 3:37:10 PM UTC-5, Ryan Hurst wrote:
> > 
> > What about "or a user supplied password"?
> > -carl
> 
> user supplied passwords will (in real world scenarios) not be as good as a 
> one generated for them; this is in part why I suggested earlier if a user 
> password to be used that it be mixed with a server provided value.

True, but CAs can put technical constraints on that to limit the acceptable 
passwords to a certain strength. (hopefully with a better strength-testing 
algorithm than the example Tim gave earlier)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Wayne Thayer via dev-security-policy]

On Fri, May 4, 2018 at 1:25 PM Carl Mehner via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hey Doug,
>
> On Friday, May 4, 2018 at 3:00:03 PM UTC-5, Doug Beattie wrote:
> > Hey Wayne,
> >
> > This should be a really easy thing, but it's not.
> >
> > First comments on this: "MUST be encrypted and signed; or, MUST have a
> password that..."
> > - Isn't the password the key used for encryption?  I'm not sure if the
> "or" makes sense since in both cases the password is the key for encryption
>
> The password is used through a round of hashes (or a pbkdf, depending on
> the algorithm) to create a set of bits that are used as a key. (see
> paragraph 6 here: https://www.cem.me/20150315-cert-binaries-6.html)
>
> > - In general, I don't think PKCS#12 files are signed, so I'd leave that
> out, a signature isn't necessary.  I could be wrong...
>
> That goes back to Ryan's comment here:
>
> https://groups.google.com/d/msg/mozilla.dev.security.policy/SYC0d1YgXtI/slRunsYbAgAJ
> "PKCS#12 supports both symmetric and asymmetric key based protection also."
>
> >
Yes, that is the intent. If my wording is poor, please suggest improvements.
>

>
>
> > I'd still like to see a modification on the requirement: "password MUST
> be transferred using a different channel than the PKCS#12 file".  A user
> should be able to download the P12 and password via HTTP.  Can we add an
> exception for that?
>
> >
I'd like to hear from others who think this is needed.
>

> What about "or a user supplied password"?
>
>
Doesn't the current language already permit this? It does make sense if
you're suggesting it to Doug as a workaround.
>

> -carl
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ryan Hurst 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.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ryan Hurst via dev-security-policy]

On Friday, May 4, 2018 at 1:00:03 PM UTC-7, Doug Beattie wrote:
> First comments on this: "MUST be encrypted and signed; or, MUST have a 
> password that..."
> - Isn't the password the key used for encryption?  I'm not sure if the "or" 
> makes sense since in both cases the password is the key for encryption

There are modes of PKCS#12 that do not use passwords.

> - In general, I don't think PKCS#12 files are signed, so I'd leave that out, 
> a signature isn't necessary.  I could be wrong...

They may be, see: http://unmitigatedrisk.com/?p=543

> 
> I'd still like to see a modification on the requirement: "password MUST be 
> transferred using a different channel than the PKCS#12 file".  A user should 
> be able to download the P12 and password via HTTP.  Can we add an exception 
> for that?

Why do you want to allow the use of HTTP?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Carl Mehner via dev-security-policy]

Hey Doug,

On Friday, May 4, 2018 at 3:00:03 PM UTC-5, Doug Beattie wrote:
> Hey Wayne,
> 
> This should be a really easy thing, but it's not.
> 
> First comments on this: "MUST be encrypted and signed; or, MUST have a 
> password that..."
> - Isn't the password the key used for encryption?  I'm not sure if the "or" 
> makes sense since in both cases the password is the key for encryption

The password is used through a round of hashes (or a pbkdf, depending on the 
algorithm) to create a set of bits that are used as a key. (see paragraph 6 
here: https://www.cem.me/20150315-cert-binaries-6.html)

> - In general, I don't think PKCS#12 files are signed, so I'd leave that out, 
> a signature isn't necessary.  I could be wrong...

That goes back to Ryan's comment here:
https://groups.google.com/d/msg/mozilla.dev.security.policy/SYC0d1YgXtI/slRunsYbAgAJ
"PKCS#12 supports both symmetric and asymmetric key based protection also."



> I'd still like to see a modification on the requirement: "password MUST be 
> transferred using a different channel than the PKCS#12 file".  A user should 
> be able to download the P12 and password via HTTP.  Can we add an exception 
> for that?

What about "or a user supplied password"?
-carl
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[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
- In general, I don't think PKCS#12 files are signed, so I'd leave that out, a 
signature isn't necessary.  I could be wrong...

I'd still like to see a modification on the requirement: "password MUST be 
transferred using a different channel than the PKCS#12 file".  A user should be 
able to download the P12 and password via HTTP.  Can we add an exception for 
that?

Doug

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of Wayne
> Thayer via dev-security-policy
> Sent: Friday, May 4, 2018 2:58 PM
> To: mozilla-dev-security-policy 
> <mozilla-dev-security-pol...@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-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[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
proposal that attempts to account for most of the input we've received:

Add the following to section 5.2 (Forbidden and Required Practices):

CAs MUST NOT generate the key pairs for end-entity certificates that have
> an EKU extension containing the KeyPurposeIds id-kp-serverAuth or
> anyExtendedKeyUsage.
>
> PKCS#12 files must employ an encryption algorithm that is sufficiently
> strong to protect the key pair for its useful life based on current
> guidelines published by a recognized standards body. PKCS#12 files MUST be
> encrypted and signed; or, MUST have a password that exhibits at least 112
> bits of entropy, and the password MUST be transferred using a different
> channel than the PKCS#12 file.
>

This isn't perfect. I would appreciate your comments if you have
significant concerns with this proposed policy.

- Wayne
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Tim Hollebeek via dev-security-policy]

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

Doh!  Yes.

-Tim



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Kurt Roeckx via dev-security-policy]

On 2018-05-04 12:10, Tim Hollebeek wrote:

It has generally been understood that a string still "contains at least 112
bits of output from a CSPRNG" if that string has been fed through an
encoding mechanism like Base64 or Base32.

Furthermore, explicit requirements about including mixed case or special
characters leads to some very, very bad and borderline toxic security
requirements.  NIST has recently recanted and admitted they were very, very
wrong in this area and we should not repeat their mistake.

Anything we can do to clarify that an awesome password is:

string password = Base32.Encode(CSPRNG.ReadBytes(n));

where n >= 112, we should do.


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

> BTW United Airlines rates these sorts of passwords as "medium strength".
> Password meters that only pay attention to password complexity and not
> length are stupid.

And then you have sites that have a problem with passwords longer than 
12 characters, where you can't the base64 characters. Or where you log 
in using the number of your card and a pin number limited to 6 digits.



Kurt
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

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

Anything we can do to clarify that an awesome password is:

string password = Base32.Encode(CSPRNG.ReadBytes(n));

where n >= 112, we should do.

BTW United Airlines rates these sorts of passwords as "medium strength".
Password meters that only pay attention to password complexity and not
length are stupid.

-Tim

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of
Buschart,
> Rufus via dev-security-policy
> Sent: Thursday, May 3, 2018 6:01 PM
> To: Carl Mehner <c...@cem.me>; mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key
> generation to policy)
> 
> Basically I like the new wording:
> 
> > PKCS#12 files [...] SHALL have a password containing at least 112 bits
> > of output from a CSPRNG, [...]
> 
> But I think there is a practical problem here: Directly using the output
of any
> random number generator ("C" or not) to generate a password will lead to
> passwords which contain most probably characters that are either not
> printable or at least not type-able on a 'normal' western style keyboard.
> Therefore I think we need to reword the password strength section a little
bit,
> maybe like the following:
> 
> > PKCS#12 files [...] SHALL have a 14 character long password consisting
> > of characters, digits and special characters based on output from a
> > CSPRNG, [...]
> 
> When I originally proposed my wording, I had the serial numbers in my mind
> (for which directly using the output of a CSPRNG works), but didn't think
on the
> encoding problem.
> 
> 
> With best regards,
> Rufus Buschart
> 
> Siemens AG
> Information Technology
> Human Resources
> PKI / Trustcenter
> GS IT HR 7 4
> Hugo-Junkers-Str. 9
> 90411 Nuernberg, Germany
> Tel.: +49 1522 2894134
> mailto:rufus.busch...@siemens.com
> www.twitter.com/siemens
> 
> www.siemens.com/ingenuityforlife
> 
> Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim
Hagemann
> Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive
> Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik
Neike,
> Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich,
Germany;
> Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684;
> WEEE-Reg.-No. DE 23691322
> 
> 
> > -Ursprüngliche Nachricht-
> > Von: dev-security-policy
> > [mailto:dev-security-policy-bounces+rufus.buschart=siemens.com@lists.m
> > ozilla.org] Im Auftrag von Carl Mehner via dev-security-policy
> > Gesendet: Mittwoch, 2. Mai 2018 07:45
> > An: mozilla-dev-security-pol...@lists.mozilla.org
> > Betreff: Re: Policy 2.6 Proposal: Add prohibition on CA key generation
> > to policy
> >
> > On Tuesday, May 1, 2018 at 6:40:53 PM UTC-5, Wayne Thayer wrote:
> > > Ryan - thanks for raising these issues again. I still have concerns
> > > about getting this specific in the policy, but since we're now
> > > headed down that road...
> > >
> > > On Tue, May 1, 2018 at 7:13 PM, Ryan Hurst via dev-security-policy <
> > > dev-security-policy@lists.mozilla.org> wrote:
> > >
> > > > A few problems I see with the proposed text:
> > > >
> > > > - What is sufficient? I would go with a definition tied to the
> > > > effective strength of the keys it protects; in other words, you
> > > > should protect a 2048bit RSA key with something that offers
> > > > similar properties or that 2048bit key does not live up to its
> > > > 2048 bit properties. This is basically the same CSPRNG
> > > > conversation but it's worth looking at
> > > >
> https://clicktime.symantec.com/a/1/MiD2ZQaRtfOOhnoE5EIpI34AP9rvA3o
> > > >
> INRRu6XdViYU=?d=5Cqt01e3JJ5HJjzKGE6nRW54FeE3IwbVJCyLgL32Lilma6QZm
> k
> > > > H2jvdL5ebp7STf-GpEiDhzmVlSKWJlJz8rGU-
> hyb22kClbCdDKNFH0hcAHEjtrhmva
> > > > pCtr5kNgTYlIotEeIpk2tXzkeWzMD-
> zxkh7R7mriLhGO5p2EWRejSrwIHrBj4b1wF0
> > > > b_wYIQDNW12oF8hKmnVApkn0sJxGRbcSk1-Pw-
> 0cO9oCmj7Ykt

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

[Dimitris Zacharopoulos via dev-security-policy]

As I was reading this very interesting thread, I kept asking myself 
"what are we trying to protect". Are we trying to protect a "Private 
Key" or a "PKCS#12" file? I suppose the consensus of the community, 
based mainly on compatibility issues, is that we can't avoid the 
solution of a PKCS#12 file, so we need to figure out how to send this 
file with reasonable security to the Subscriber.


We have two areas of concern:

1. How to prevent an attacker from getting the PKCS#12 file
2. If an attacker obtains the PKCS#12 file, make sure the encryption is
   reasonable and endurable to practically sustain a decryption attempt
   that would practically take longer to crack than the lifetime of the
   Certificate

For area 1, the file must be distributed via secure channel. Some 
recommendations:


1. Web page (protected by https) via authentication of the Subscriber
2. S/MIME encrypted email by using an existing Subscriber valid
   Certificate
3. Some might also use pgp for S/MIME
4. Registered post, if delivered in a simple USB
5. Registered, or not registered post, if delivered in a FIPS 140-2
   Level 3 USB drive
6. ...
7. ...

Do we need to expand on this list? What if there are other 
equally-secure methods that we haven't listed? This definitely doesn't 
look like a policy text to me. It describes very specific 
practices/procedures that should be the CA's job to discover and 
Auditor's to verify, but I also understand that in practice, some CAs 
haven't demonstrated good judgment on these topics and auditors didn't 
help either.


For area 2, obviously, if an attacker obtains the PKCS#12 file and has 
infinite time, the key will be decrypted. I believe the discussion 
resulted in two dominating factors:


 * The encryption algorithms in the PKCS#12 file
 * The password quality

For the encryption algorithms, I recommend that we defer to other 
organization's guidelines, such as SOGIS, NIST or ETSI, that have 
extensively studied the "strength" of encryption algorithms. I can't 
tell if this community or Mozilla is confident enough to choose a 
specific set of "approved" encryption algorithms.


For the password quality, we should follow the definition of a "Random 
Value" as described in the Baseline Requirements


*"Random Value*: A value specified by a CA to the Applicant that 
exhibits at least 112 bits of entropy."


And yes, I would also recommend the usage of a CSPRNG. With that said, 
even if this process (performed by the CA) produces complex passwords 
that contain special characters and (in an unlikely event) might take 20 
minutes to type, it is still going to be used "just once" and the 
Subscriber can then do whatever he/she wants with it. The Subscriber can 
change the passphrase to "1234" for all we care. As far as the CA is 
concerned, the main job is done. The file has been encrypted with a 
reasonably secure algorithm and protected with a reasonably secure 
passphrase.


Of course the passphrase will be delivered separately!

Finally, I would like to ask if the community thinks that it's 
reasonable to put all of our protection efforts on area 2. If we raise 
the bar on area 2 (the proper protection of the PKCS#12 file), we don't 
need to worry "too much" about area 1. We could even send a file via 
plain e-mail because it won't matter if the attacker obtains the file. 
It is already encrypted securely. I would still recommend both but I 
also understand the convenience of the Subscribers and the delivery 
methods for some of these files in types of devices that I am not aware 
of (IoT, some smart phones, etc).



Dimitris.


On 4/5/2018 1:01 πμ, Buschart, Rufus via dev-security-policy wrote:

Basically I like the new wording:


PKCS#12 files [...] SHALL have a password containing at least 112 bits
of output from a CSPRNG, [...]

But I think there is a practical problem here: Directly using the output of any random 
number generator ("C" or not) to generate a password will lead to passwords 
which contain most probably characters that are either not printable or at least not 
type-able on a 'normal' western style keyboard. Therefore I think we need to reword the 
password strength section a little bit, maybe like the following:


PKCS#12 files [...] SHALL have a 14 character long password consisting
of characters, digits and special characters based on output from a
CSPRNG, [...]

When I originally proposed my wording, I had the serial numbers in my mind (for 
which directly using the output of a CSPRNG works), but didn't think on the 
encoding problem.


With best regards,
Rufus Buschart

Siemens AG
Information Technology
Human Resources
PKI / Trustcenter
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.twitter.com/siemens

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive 

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

[Buschart, Rufus via dev-security-policy]

Basically I like the new wording:

> PKCS#12 files [...] SHALL have a password containing at least 112 bits 
> of output from a CSPRNG, [...]

But I think there is a practical problem here: Directly using the output of any 
random number generator ("C" or not) to generate a password will lead to 
passwords which contain most probably characters that are either not printable 
or at least not type-able on a 'normal' western style keyboard. Therefore I 
think we need to reword the password strength section a little bit, maybe like 
the following:

> PKCS#12 files [...] SHALL have a 14 character long password consisting 
> of characters, digits and special characters based on output from a 
> CSPRNG, [...]

When I originally proposed my wording, I had the serial numbers in my mind (for 
which directly using the output of a CSPRNG works), but didn't think on the 
encoding problem.


With best regards,
Rufus Buschart

Siemens AG
Information Technology
Human Resources
PKI / Trustcenter
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.twitter.com/siemens

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive 
Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, 
Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; 
Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; 
WEEE-Reg.-No. DE 23691322


> -Ursprüngliche Nachricht-
> Von: dev-security-policy
> [mailto:dev-security-policy-bounces+rufus.buschart=siemens.com@lists.m
> ozilla.org] Im Auftrag von Carl Mehner via dev-security-policy
> Gesendet: Mittwoch, 2. Mai 2018 07:45
> An: mozilla-dev-security-pol...@lists.mozilla.org
> Betreff: Re: Policy 2.6 Proposal: Add prohibition on CA key generation 
> to policy
> 
> On Tuesday, May 1, 2018 at 6:40:53 PM UTC-5, Wayne Thayer wrote:
> > Ryan - thanks for raising these issues again. I still have concerns 
> > about getting this specific in the policy, but since we're now 
> > headed down that road...
> >
> > On Tue, May 1, 2018 at 7:13 PM, Ryan Hurst via dev-security-policy < 
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> > > A few problems I see with the proposed text:
> > >
> > > - What is sufficient? I would go with a definition tied to the 
> > > effective strength of the keys it protects; in other words, you 
> > > should protect a 2048bit RSA key with something that offers 
> > > similar properties or that 2048bit key does not live up to its
> > > 2048 bit properties. This is basically the same CSPRNG 
> > > conversation but it's worth looking at https://www.keylength.com/
> >
> >
> > The latest proposal replaces "sufficient" with "at least 64 bits of 
> > output from a CSPRNG". We could go back to "sufficient strength for 
> > the keys it protects", but that also leaves quite a bit of room for 
> > misinterpretation.
> >
> > Are there objections to "at least 112 bits of output from a CSPRNG" 
> > as Tim proposed?
> 
> I'd recommend making a requirement that it be "protected" by at least 
> as many bits of strength as the key it protects. Not doing so could cause 
> compliance issues: things like PCI [1] and the NIST [2] recommendations 
> require this type of protection.
> However, like Wayne said, this still leaves room for interpretation, 
> if mentioning bits is necessary, can we just bump it up to 256 rather than 
> 112?
> 
> I went back to the word "protect" to rule out the use of 3DES because 
> bumping up the password past 112 bits doesn't really do much good if the 
> underlying algorithm maxes out its protective strength at 112.
> I realize this will decrease the utility of the p12/pfx files since 
> none of the  adequately protected files would be openable on any 
> version of Windows. However, the team at Microsoft is well aware of this and 
> they can prioritize their own backlog (they just don't appear to have been 
> given the right incentive to do so as of yet). Perhaps we can add a 
> date-gate..
> 
> How about:
> 
> PKCS#12 files SHALL be encrypted and signed; or, SHALL have a password 
> containing at least 112 bits of output from a CSPRNG, and the password 
> SHALL be transferred using a different channel than the PKCS#12 file. 
> Beginning January 1, 2020 PKCS#12 files must be protected by at least 256 
> bits of output from a CSPRNG.
> 
> This would give people like Microsoft some extra time to update their 
> implementations to support AES.
> 
> 
> -Carl
> 
> [1] PCI - DSS v3.2, Section 3.5
> [2] 800-57 Part 1, Section 6.2.1.3 -
> https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt
> 1r4.pdf ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

[Buschart, Rufus via dev-security-policy]

---=== Intern ===---
Hello!

I would like to suggest to rephrase the central sentence a little bit:

Original:

CAs MUST NOT distribute or transfer certificates in PKCS#12 form through 
insecure electronic channels. The PKCS#12 file must have a  sufficiently secure 
password, and the password must not be transferred  together with the file.

Proposal:

CAs SHOULD NOT distribute or transfer certificates in PKCS#12 form through 
insecure electronic channels. If the CA chooses to do so, the PKCS#12 file 
SHALL have a  password containing at least 32 bit of output from a CSPRNG, and 
the password SHALL be transferred using a different channel as the PKCS#12 file.


My proposal would allow a CA to centrally generate a P12 file, send it to the 
Subject by unencrypted email and send the P12 pin as a SMS or Threema message. 
This is an important use case if you want to have email encryption on a mobile 
device that is not managed by a mobile device management system. Additionally I 
made the wording a little bit more rfc2119-ish and made clear, what defines a 
'sufficiently secure password' as the original wording lets a lot of room for 
'interpretation'.

What do you think?

/Rufus


Siemens AG
Information Technology
Human Resources
PKI / Trustcenter
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.twitter.com/siemens

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive 
Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, 
Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; 
Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; 
WEEE-Reg.-No. DE 23691322

> -Ursprüngliche Nachricht-
> Von: dev-security-policy 
> [mailto:dev-security-policy-bounces+rufus.buschart=siemens.com@lists.m
> ozilla.org] Im Auftrag von Wayne Thayer via dev-security-policy
> Gesendet: Freitag, 27. April 2018 19:30
> An: Enrico Entschew
> Cc: mozilla-dev-security-policy
> Betreff: Re: Policy 2.6 Proposal: Add prohibition on CA key generation 
> to policy
> 
> On Fri, Apr 27, 2018 at 6:40 AM, Enrico Entschew via dev-security-policy < 
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > I suggest to make the requirement „* The PKCS#12 file must have a 
> > sufficiently secure password, and the password must be transferred 
> > via a separate channel than the PKCS#12 file.” binding for both 
> > transfer methods and not be limited to physical data storage.
> > Otherwise I agree with this proposal.
> >
> > Enrico
> >
> > That seems like a good and reasonable change, resulting in the 
> > following
> policy:
> 
> CAs MUST NOT generate the key pairs for end-entity certificates that 
> have EKU extension containing the KeyPurposeIds id-kp- serverAuth or 
> anyExtendedKeyUsage.
> 
> CAs MUST NOT distribute or transfer certificates in PKCS#12 form 
> through insecure electronic channels. The PKCS#12 file must have a 
> sufficiently secure password, and the password must not be transferred 
> together with the file. If a PKCS#12 file is distributed via a 
> physical data storage device, then the storage must be packaged in a 
> way that the opening of the package causes irrecoverable physical 
> damage. (e.g. a security seal)
> 
> Unless other comments are made, I'll consider this to be the conclusion of 
> discussion on this topic.
> 
> Wayne
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy