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

CT Log deprecation

[Jeremy Rowley via dev-security-policy]

Hi everyone, 

 

I posted our announcement about deprecation of Symantec CT logs over on the
Google list a while ago. I figured I'd post something here as well so the
community is aware of our plans.

 

As part of our infrastructure consolidation DigiCert will be EOLing legacy
Symantec CT log servers listed below at the end of September 2018.

https://ct.ws.symantec.com/ct/v1
(https://bugs.chromium.org/p/chromium/issues/detail?id=483625 )

https://vega.ws.symantec.com/ct/v1
(https://bugs.chromium.org/p/chromium/issues/detail?id=554549#c18 )

https://sirius.ws.symantec.com/ct/v1
(https://bugs.chromium.org/p/chromium/issues/detail?id=692782#c24 )

 

Google seems to operate mirrors for these log servers as announced here
https://www.ietf.org/mail-archive/web/trans/current/msg01485.html 

 

>>> 

- Google is building out log mirrors for all logs included by Chrome,

  and the intent is that read-only requests from Chrome (for STHes, or

  inclusion-proofs (via the DNS mechanism above)) will be serviced by a

  log mirror, rather than the underlying logs.

>>> 

 

These links show the actual mirror for each of above CT Logs:

 
https://ct.grahamedgecombe.com/logs/10

 
https://ct.grahamedgecombe.com/logs/14

 
https://ct.grahamedgecombe.com/logs/31

 

Many CAs apart from DigiCert (legacy Symantec) currently use at least one of
these log servers to log their EV/OV certificates. We strongly recommend
that CAs that currently use any of these log servers should start using any
other log servers in the CT ecosystem as soon as possible (or set up their
log). This will give these CAs enough time to secure permissions (if
required) for using an alternate log server from its operator and complete
integration with it. Legacy Symantec log servers will fully cease to operate
after EOL.

 

If you have specific questions please use the  contact email published with
each log server or contact me.

 

Jeremy



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]

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