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

[Carl Mehner via dev-security-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-57pt1r4.pdf
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Wayne Thayer via dev-security-policy]

Ryan - thanks for raising these issues again. I still have concerns about
getting this specific in the policy, but since we're now headed down that
road...

On Tue, May 1, 2018 at 7:13 PM, Ryan Hurst via dev-security-policy <
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?

>
> - The language should recommend that the "password" be a value that is a
> mix of a user-supplied value and the CSPRNG output and that the CA can not
> store the user-supplied value for longer than necessary to create the
> PKCS#12.
>

I'm with Tim on this - it's added complexity for no real added security.

- The strength of the password is discussed but PKCS#12 supports a bunch of
> weak cipher suites and it is common to find them in use in PKCS#12s. The
> minimum should be specified to be what Microsoft supports which is
> pbeWithSHAAnd3-KeyTripleDES-CBC for “privacy” of keys and for the privacy
> of certificates it uses pbeWithSHAAnd40BitRC2-CBC.
>

After reading your (Ryan's) blog, I was left with the impression that
Windows only supports the weakest algorithms, so adding this requirement
doesn't mean anything. If that's not correct, can you suggest some language?

- The language requires the use of a password when using PKCS#12s but
> PKCS#12 supports both symmetric and asymmetric key based protection also.
> While these are not broadly supported the text should not prohibit the use
> of stronger mechanisms than 3DES and a password.
>
> Does the following language work? If not, could you suggest something
better?

PKCS#12 files SHALL be encrypted and signed; or, SHALL have a password
containing at least 64 bits of output from a CSPRNG, and the password SHALL
be transferred using a different channel than the PKCS#12 file.


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

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

[Ryan Hurst via dev-security-policy]

On Tuesday, May 1, 2018 at 1:00:20 PM UTC-7, Tim Hollebeek wrote:
> I get that, but any CA that can securely erase and forget the user’s 
> contribution to the password and certainly do the same thing to the entire 
> password, so I’m not seeing the value of the extra complexity and interaction.

It forces a conscious decision to violate a core premise.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Tim Hollebeek via dev-security-policy]

I get that, but any CA that can securely erase and forget the user’s 
contribution to the password and certainly do the same thing to the entire 
password, so I’m not seeing the value of the extra complexity and interaction.

 

-Tim

 

From: Ryan Hurst [mailto:ryan.hu...@gmail.com] 
Sent: Tuesday, May 1, 2018 3:49 PM
To: Tim Hollebeek 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

 

> I'm not sure I agree with this as a recommendation; if you want both parties
> to provide inputs to the generation of the password, use a well-established
> and vetted key agreement scheme instead of ad hoc mixing.

> Of course, at that point you have a shared transport key, and you should 
> probably
> just use a stronger, more modern authenticated key block than PKCS#12,
> but that's a conversation for another day.

 

I say this because it is desirable that the CA plausibly not be able to decrypt 
the key even if it holds the encrypted key blob.

 

 

 

On Tue, May 1, 2018 at 12:40 PM, Tim Hollebeek mailto:tim.holleb...@digicert.com> > wrote:


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

Yup, this is the typical position of standards bodies for crypto stuff.  I 
noticed that
the 32 got fixed to 64, but it really should be 112.

> - The language should recommend that the "password" be a value that is a mix
> of a user-supplied value and the CSPRNG output and that the CA can not store
> the user-supplied value for longer than necessary to create the PKCS#12.

I'm not sure I agree with this as a recommendation; if you want both parties
to provide inputs to the generation of the password, use a well-established
and vetted key agreement scheme instead of ad hoc mixing.

Of course, at that point you have a shared transport key, and you should 
probably
just use a stronger, more modern authenticated key block than PKCS#12,
but that's a conversation for another day.

> - The language requires the use of a password when using PKCS#12s but
> PKCS#12 supports both symmetric and asymmetric key based protection also.
> While these are not broadly supported the text should not probit the use of
> stronger mechanisms than 3DES and a password.

Strongly agree.

-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: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

[Ryan Hurst via dev-security-policy]

> I'm not sure I agree with this as a recommendation; if you want both
parties
> to provide inputs to the generation of the password, use a
well-established
> and vetted key agreement scheme instead of ad hoc mixing.

> Of course, at that point you have a shared transport key, and you should
> probably
> just use a stronger, more modern authenticated key block than PKCS#12,
> but that's a conversation for another day.

I say this because it is desirable that the CA plausibly not be able to
decrypt the key even if it holds the encrypted key blob.



On Tue, May 1, 2018 at 12:40 PM, Tim Hollebeek 
wrote:

>
> > - 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.
>
> Yup, this is the typical position of standards bodies for crypto stuff.  I
> noticed that
> the 32 got fixed to 64, but it really should be 112.
>
> > - The language should recommend that the "password" be a value that is a
> mix
> > of a user-supplied value and the CSPRNG output and that the CA can not
> store
> > the user-supplied value for longer than necessary to create the PKCS#12.
>
> I'm not sure I agree with this as a recommendation; if you want both
> parties
> to provide inputs to the generation of the password, use a well-established
> and vetted key agreement scheme instead of ad hoc mixing.
>
> Of course, at that point you have a shared transport key, and you should
> probably
> just use a stronger, more modern authenticated key block than PKCS#12,
> but that's a conversation for another day.
>
> > - The language requires the use of a password when using PKCS#12s but
> > PKCS#12 supports both symmetric and asymmetric key based protection also.
> > While these are not broadly supported the text should not probit the use
> of
> > stronger mechanisms than 3DES and a password.
>
> Strongly agree.
>
> -Tim
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ryan Hurst via dev-security-policy]

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 language should recommend that the "password" be a value that is a mix of 
a user-supplied value and the CSPRNG output and that the CA can not store the 
user-supplied value for longer than necessary to create the PKCS#12.
- The strength of the password is discussed but PKCS#12 supports a bunch of 
weak cipher suites and it is common to find them in use in PKCS#12s. The 
minimum should be specified to be what Microsoft supports which is 
pbeWithSHAAnd3-KeyTripleDES-CBC for “privacy” of keys and for the privacy of 
certificates it uses pbeWithSHAAnd40BitRC2-CBC.
- The language requires the use of a password when using PKCS#12s but PKCS#12 
supports both symmetric and asymmetric key based protection also. While these 
are not broadly supported the text should not probit the use of stronger 
mechanisms than 3DES and a password.

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

OISTE WISeKey Global Root GC CA Root Inclusion Request

[Wayne Thayer via dev-security-policy]

This request is for inclusion of the OISTE WISeKey Global Root GC CA as
documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1403591

* BR Self Assessment is here:
https://bugzilla.mozilla.org/attachment.cgi?id=8912732

* Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=8955363

* Root Certificate Download URL:
https://bugzilla.mozilla.org/attachment.cgi?id=8912737

CP/CPS:
https://cdn.wisekey.com/uploads/images/WKPKI.DE001-OWGTM-PKI-CPS.v2.10-CLEAN.pdf

* This request is to turn on the Websites and Email trust bits. EV
treatment is not requested.

* EV Policy OIDs: Not EV

* Test Websites
https://gcvalidssl.hightrusted.com/
https://gcexpiredssl.hightrusted.com/
https://gcrevokedssl.hightrusted.com/

* CRL URL: http://public.wisekey.com/crl/wcidgcas1.crl

* OCSP URL: http://ocsp.wisekey.com/

* Audit: Annual audits are performed by AUREN according to the WebTrust for
CA and BR audit criteria.
WebTrust:
https://cdn.wisekey.com/uploads/images/Audit-Report-and-Management-Assertions-Webtrust-CA-GC.pdf
BR:
https://cdn.wisekey.com/uploads/images/Audit-Report-and-Management-Assertions-Webtrust-BR-GC.pdf
EV: Not EV

I’ve reviewed the CPS, BR Self Assessment, and related information for the
OISTE WISeKey Global Root GC CA inclusion request that are being tracked in
this bug and have the following comments:

==Good==
* This root was created in May of 2017 and the intermediate appears to have
only signed test certs since then.
* Problem reporting mechanism is clearly labeled as such in the CPS.

==Meh==
* The older OISTE WISeKey Global Root GA CA that is in our program has
issued a few certs containing linting errors (some are false positives for
OCSP signing certs):
https://crt.sh/?caid=15102&opt=cablint,zlint,x509lint&minNotBefore=2010-01-01
Two notable concerns are:
** Valid wildcard certificate for a public suffix:
https://crt.sh/?id=76535370&opt=cablint (BR 3.2.2.6 permits this only if
“the applicant proves its rightful control of the entire Domain Namespace“)
** Valid cert containing a non-printable string in the Subject :
https://crt.sh/?id=308365498&opt=x509lint,ocsp
* WISeKey was the subject of one misissuance bug for “invalid dnsNames” and
“CN not in SAN” errors to which they responded promptly:
https://bugzilla.mozilla.org/show_bug.cgi?id=1391089
** They also failed to respond to a problem report during this incident.
Domain validations procedures are listed in an appendix instead of section
3.2.2.4 of the CPS and they include the soon-to-be-banned 3.2.2.4.1 and
3.2.2.4.5 methods. A note indicates that 3.2.2.4.5 will be discontinued
after August 1st. The reference to 3.2.2.4.1 appears to be a documentation
error.
During my initial review, the CPS was missing CAA information and still
referenced 3-year validity periods. WISeKey quickly made the needed changes
but indicated that they update their CPS during an annual review rather
than regularly as new requirements come into effect.

==Bad==
Nothing to report

This begins the 3-week comment period for this request [1].

I will greatly appreciate your thoughtful and constructive feedback on the
acceptance of this root into the Mozilla CA program.

- Wayne

[1] https://wiki.mozilla.org/CA/Application_Process
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.6 Proposal: Require separate intermediates for different usages (e.g. server auth, S/MIME)

[Wayne Thayer via dev-security-policy]

Jakob,

On Tue, May 1, 2018 at 1:14 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote

>
> However maybe an additional (clarifying or new) requirement set:
>
> I think the existing language in section 5.3.1 covers all of this. If not,
can you point out the gaps so that I can open a new issue?

To be considered as a name constrained SubCA, the SubCA certificate must
> satisfy all of the following:
>
> 1. Specify a specific non-empty list or permitted EKUs, which does not
>   include the value anyExtendedKeyUsage.
>
> 2. Specify name constraints (whitelist-based) for all the name types
>   that can be used with the specified permitted EKUs.  Any EV-capable
>   such SubCA must also specify name constraints for the directory name
>   type.
>
> 3. Each name constraint must permit only names for which the holder of
>   the name constrained CA has been fully vetted as ultimately
>   authoritative.  For example, any DNS names must correspond to domains
>   registered to the holder for a registration period completely
>   overlapping the CA cert validity period.  Any Distinguished name must
>   correspond to the verified real world identity of the holder (for
>   example C=US, O=Google Inc would be a permitted dirname subtree
>   constraint for a subCA issued to the US headquarters of Google Inc.
>   The validation must be done to standards above and beyond the
>   standards required for end entity certific
> ates
> of the types that the
>   SubCA can issue.
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.6 Proposal: Require separate intermediates for different usages (e.g. server auth, S/MIME)

[Jakob Bohm via dev-security-policy]

On 30/04/2018 18:47, Wayne Thayer wrote:

On Mon, Apr 30, 2018 at 8:27 AM, Ryan Sleevi  wrote:




On Wed, Apr 25, 2018 at 1:03 PM, Wayne Thayer  wrote:


On Tue, Apr 24, 2018 at 9:24 AM, Ryan Sleevi  wrote:


I'm not sure I underestand the use case. I'm hoping that they can
clarify more.

Pedro - can you explain more about why this is important?


That is, it would seem valuable as part of the technical constraint

exercise to ensure the EKUs are restsricted. This is particularly true due
to how nameConstraints work - they are blacklists (effectively), rather
than whitelists, which means that combined with EKUs, they can be used for
unconstrained purposes.

Similar to the discussions regarding nameConstraints and name types,
this has the effect of discouraging the introduction of new EKUs, as such
intermediates would be unconstrained for these potential new and novel EKU
use cases.

Ryan - can you explain this concern in more detail? If, for instance,

the srvName type was added for TLS certificates, new intermediates would be
required to constrain that name type due to the "fail open" nature of name
constraints. If a single intermediate contained both the serverAuth and
emailProtection EKUs, how does that make the situation worse? Is it just
that now all of the S/MIME certificates issued under the intermediate  must
also expire or be replaced so that the old intermediate (without a
constraint on srvName) can be revoked?



You're absolutely correct that if an intermediate certificate contains
serverAuth and emailProtection EKUs, then we are bounded in the types of
certificates it issues. It is only in the situation where it lacks an EKU,
or where it's granted the anyExtendedKeyusage EKU, that we're in a
situation where we're failing "open".

My understanding of the proposal to "make an exception" for
nameConstrained CAs was to allow any of these - that is, a combination of
explicit EKUs, lacking an EKU, and an anyEKU. The consequence of this would
be that the introduction of srvName for TLS, in the case of (lacking an
EKU, any EKU), would mean that such an intermediate is unconstrained for
TLS issuance - even if it was only 'intended' for something such as S/MIME
and smart-card auth.

If the proposal is to allow multiple (explicit) EKUs on an intermediate,
when the intermediate also has constraints appropriate for each of the
enumerated EKUs, then I think we're in a better place, although we should
understand the motivation more :)



This proposal wouldn't change the current requirement for technically
constrained intermediates:

For a certificate to be considered technically constrained, the certificate
MUST include an Extended Key Usage (EKU) extension specifying all extended
key usages that the subordinate CA is authorized to issue certificates for.
The anyExtendedKeyUsage KeyPurposeId MUST NOT appear within this extension.



However maybe an additional (clarifying or new) requirement set:

To be considered as a name constrained SubCA, the SubCA certificate must
satisfy all of the following:

1. Specify a specific non-empty list or permitted EKUs, which does not
  include the value anyExtendedKeyUsage.

2. Specify name constraints (whitelist-based) for all the name types
  that can be used with the specified permitted EKUs.  Any EV-capable
  such SubCA must also specify name constraints for the directory name
  type.

3. Each name constraint must permit only names for which the holder of
  the name constrained CA has been fully vetted as ultimately
  authoritative.  For example, any DNS names must correspond to domains
  registered to the holder for a registration period completely
  overlapping the CA cert validity period.  Any Distinguished name must
  correspond to the verified real world identity of the holder (for
  example C=US, O=Google Inc would be a permitted dirname subtree
  constraint for a subCA issued to the US headquarters of Google Inc.
  The validation must be done to standards above and beyond the
  standards required for end entity certificates of the types that the
  SubCA can issue.



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