Support enforcing nested EKU constraints, do so by default.

NEW
Unassigned

Status

defect
7 years ago
2 years ago

People

(Reporter: ryan.hurst, Unassigned)

Tracking

(Depends on 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

7 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.77 Safari/535.7

Steps to reproduce:

The PKIX path validation engine on Windows implements a concept called nested EKU enforcement. What this does is require there to be consistency in the EKUs within a chain, for example if I have a certificate chain of:

root (no EKU), intermediate (EKU of S/MIME), and leaf (EKU of Server SSL Authentication)

It would be considered invalid on applications that use the Windows chain engine (CertGetCertificateChain), it would however be valid on Mozilla.

The concept represented here is technically not conforming with the associated RFCs in that they say:

"In general, this extension will appear only in end entity certificates."

And do not define what the behavior is when they exist in the intermediates; however support of the behavior implemented by Windows offers an important trait, the ability to delegate the right to issue only a certain type of certificate.

Imagine a enterprise that has only a few web servers and is fine having the issuance process managed by a third-party but has hundreds of thousands of email certificates that they would like to have trusted externally.

They are the best suited to vet those email addresses and allowing them to be subordinated by a trusted CA with the constrained scope of just email allows this to happen.

One could argue that a certificate that limits the scope of the certificate via name constraints can offer the same capability in that if the name form that the scenario is dependent on is bound to the scope specified in the name constraint they can not issue that certificate.

While it is generally true there are cases where it is not, for example where a web-server certificate should contain a contact email address.


Actual results:

Today such a certificate chain would validate.


Expected results:

By default, such chains should be captured as invalid.
(Reporter)

Updated

7 years ago
Component: Security → Libraries
Product: Core → NSS
Version: 13 Branch → 4.0

Updated

7 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 7 → All
QA Contact: toolkit → libraries
Hardware: x86_64 → All
Version: 4.0 → trunk
(Reporter)

Comment 1

7 years ago
I thought I would add that I confirmed with Stephen Henson that OpenSSL also adopted this semantic, at least for the validation of server certificates.

Additionally it has been brought to my attention that some may have concerns relating to IPR on checking the EKU in the way specified, while I can no longer speak for MS I know we made efforts to get others to adopt the same scheme as we felt it would help prevent some of the thins we have been seeing of late with CA subordination.

Similar concerns were made at that point even though I (on behalf of MS at the time) made it clear we had no interest in such things; I would be more than willing to find the current owner in MSFT to re-assert such a statement I am confident they would feel the same way still.

As for how its implemented, in the case of OpenSSL they did a simple check to ensure the immediate CA has that EKU. That is sufficient to get the value proposition discussed above (at least for SSL).

In the case of Microsoft's implementation the same check is done all the way to the root, it is done using the same logic that does name constraints verification.

Comment 2

7 years ago
The NSS code implements a similiar semantic, at least as far as certificate type goes. There are hints that the cert type is enforced in the NSS pkix path validation, but not in the traditional NSS path validation code.

bob
(Reporter)

Comment 3

7 years ago
Bob,

Would be great to see this happen in a uniform way; its very valuable to constrained delegation scenarios IMHO.

Ryan
(Reporter)

Comment 4

7 years ago
Blog post on this concept and how it reduced risk for MSFT in the Flame incident - http://rmhrisk.wpengine.com/?p=57

Comment 5

7 years ago
It was noted in mozilla.dev.security.policy that the implementation should require that the EKU be specified in each intermediate certificate of the cert chain. For instance, when code signing is granted at one level, but then the intermediate cert that it signs does not specify code signing in the EKU, then that intermediate cert should not be able to grant code signing to the end-entity cert. In other words, there should not be "Effective EKUs" as described here: http://rmhrisk.wpengine.com/?p=57

Comment 6

7 years ago
(In reply to Kathleen Wilson from comment #5)
> It was noted in mozilla.dev.security.policy that the implementation should
> require that the EKU be specified in each intermediate certificate of the
> cert chain. For instance, when code signing is granted at one level, but
> then the intermediate cert that it signs does not specify code signing in
> the EKU, then that intermediate cert should not be able to grant code
> signing to the end-entity cert. In other words, there should not be
> "Effective EKUs" as described here: http://rmhrisk.wpengine.com/?p=57

Seriously?

This is what the Policies extension is for, and Policies has the benefit that it was designed with this kind of control in mind.

Comment 7

7 years ago
(In reply to Kyle Hamilton from comment #6)
> 
> This is what the Policies extension is for, and Policies has the benefit
> that it was designed with this kind of control in mind.

This bug is basically requesting support in the libpkix code in NSS for the proposed policy updates, item #9 of
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html

These policy updates have been discussed in the mozilla.dev.security.policy forum. 
https://groups.google.com/forum/#!forum/mozilla.dev.security.policy
Topic: "New Proposed policy for Externally-Operated subCAs"
Direct link:
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/0jnELviAxxo

Comment 8

7 years ago
Kyle, Windows actually uses the same processing semantics as the policy extension but EKU and policies have very different purposes.

   In an end entity certificate, these policy information terms indicate
   the policy under which the certificate has been issued and the
   purposes for which the certificate may be used.

For example a certificate policy might discuss roles and vulnerabilities of the actors.

Extended Key Usage is not about roles and responsibilities, its about entitlements and constraints; e.g. you are entitled to use the credential for purpose X or Y.

Very different.

When looking at this behavior its important to consider that over 60% of the browsers out there already do this (IE + Chrome on Windows + misc).

I strongly feel supporting this would help Mozilla and the industry better manage subordinated CAs under publicly trusted anchors.

Comment 9

7 years ago
(In reply to Ryan Hurst from comment #0)
> The concept represented here is technically not conforming with the
> associated RFCs in that they say:
> 
> "In general, this extension will appear only in end entity certificates."
> 
> And do not define what the behavior is when they exist in the intermediates;
> however support of the behavior implemented by Windows offers an important
> trait, the ability to delegate the right to issue only a certain type of
> certificate.

I was just made aware of the existence of this bug report, and I disagree with this comment entirely.  The entire text from which the above sentence is quoted says:

   "This extension indicates one or more purposes for which the certified
   public key may be used, in addition to or in place of the basic
   purposes indicated in the key usage extension.  In general, this
   extension will appear only in end entity certificates."

Later on RFC 5280 says:

   "If the extension is present, then the certificate MUST only be used
   for one of the purposes indicated."

   "If a certificate contains both a key usage extension and an extended
   key usage extension, then both extensions MUST be processed
   independently and the certificate MUST only be used for a purpose
   consistent with both extensions.  If there is no purpose consistent
   with both extensions, then the certificate MUST NOT be used for any
   purpose."

This text is very clear the the extended key usage extension specifies the purposes for which the subject public key in the certificate containing the extension may be used.  This proposal is an attempt to redefine the extension to impose constraints on the target certificate in a certification path.

If there is such a strong belief that the extension should be interpreted in a manner similar to the way that certificatePolicies are processed, why hasn't a proposal been made to change X.509 to specify these semantics?

If NSS makes this change and then encourages CAs to include extended key usage extensions in CA certificates, that could create severe problems since many clients will process the extension correctly and will reject any intermediate certificates with an extended key usage extension, since the extension will not include any key purpose OID that permits the subject public key in the certificate to be used to verify signatures on certificates.

It would be much better to use an existing extension that already has the desired semantics, such as certificatePolicies, or define a new extension than to process an existing extension incorrectly.

Comment 10

7 years ago
(In reply to David Cooper from comment #9)
<snip>
> If NSS makes this change and then encourages CAs to include extended key
> usage extensions in CA certificates, that could create severe problems since
> many clients will process the extension correctly and will reject any
> intermediate certificates with an extended key usage extension, since the
> extension will not include any key purpose OID that permits the subject
> public key in the certificate to be used to verify signatures on
> certificates.

David, I can't fault your interpretation of RFC5280, but I suspect that practical considerations will win out here.

Many of the commercial CAs have included the EKU extension in intermediate certificates for many years.  IINM, this was necessary to activate SGC/Step-Up on IE/Netscape.  I'm not aware of any clients that have rejected these intermediate certificates on the basis that the EKU extension does "not include any key purpose OID that permits the subject public key in the certificate to be used to verify signatures on certificates."

So I'm surprised and fascinated by your "many clients" claim.  Can you name the "many clients" you were referring to?

> It would be much better to use an existing extension that already has the
> desired semantics,

Netscape defined an extension called NetscapeCertType which is still supported in NSS today, although it seems to be regarded as deprecated.  I've previously suggested "un-deprecating" NetscapeCertType instead of using EKU in intermediates in a non-RFC5280-compliant manner, but the consensus (on mozilla.dev.security.policy) was that using EKU is a better approach because it already works in both NSS and CryptoAPI (rather than just one of them).

Comment 11

7 years ago
IMO the "practical considerations" simply suck here. Especially implementors ignoring the RFC are simply changing existing security models!

Basically for PKI practitioners this means:
1. Never ever set extendedKeyUsage in intermediate certs.
2. Never ever sign certs with a key for which the accompanying public-key cert
contains the extendedKeyUsage extension.
(In reply to David Cooper from comment #9)
> If there is such a strong belief that the extension should be interpreted in
> a manner similar to the way that certificatePolicies are processed, why
> hasn't a proposal been made to change X.509 to specify these semantics?

I expect that will happen as part of the WebPKI effort at the IETF.

> If NSS makes this change and then encourages CAs to include extended key
> usage extensions in CA certificates, that could create severe problems since
> many clients will process the extension correctly and will reject any
> intermediate certificates with an extended key usage extension, since the
> extension will not include any key purpose OID that permits the subject
> public key in the certificate to be used to verify signatures on
> certificates.

How do these existing clients deal with the fact that Windows' CryptoAPI already interprets the EKU in the manner that is being suggested here?

> It would be much better to use an existing extension that already has the
> desired semantics, such as certificatePolicies, or define a new extension
> than to process an existing extension incorrectly.

I would be fine with that, if we could convince other browser makers to implement that new thing and backport it to all their widely-deployed clients with an automatic silent update in the next few months. However, I don't know if it is reasonable to expect Microsoft, Google, Apple, and Opera to all do that in that timeframe.

Note that the Go language's PKI library implements the Microsoft behavior: http://codereview.appspot.com/6304065/

+        // KeyUsage specifies which Extended Key Usage values are acceptable.
+        // An empty list means ExtKeyUsageServerAuth. Key usage is considered a
+        // constraint down the chain which mirrors Windows CryptoAPI behaviour,
+        // but not the spec. To accept any key usage, include ExtKeyUsageAny.

I think the intent of this interpretation of EKU is that a cert must (should?) be either an EE cert or a CA cert, but not both. If the cert is a CA cert and not an EE cert, then what EKU would even be meaningful for it? If the issue is that current 5280 allows a cert to be used as both an EE cert and as a CA cert, then perhaps that is something we should also change.

Comment 13

5 years ago
@(In reply to Ryan Hurst from comment #0)
> User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML,
> like Gecko) Chrome/16.0.912.77 Safari/535.7

Please follow the standard (rfc 5280) or request a change to it, and do not change the path validation algorithm on your own, for the community to have a reliable reference. Mozilla should embrace, not extend. Do not follow M$.

The validation algorithm is already too complex (and not well explained in rfc 5280). Please do not add complexity. We already have policies, name constraints, policy mappings, ... At least, you do not suggest a new extension "Extended key usage constraints" ;-)

I even dislike the extended key usage itself, key usage and basic constraints should be enough (and should be merged). In my opinion, things are already bloated, simplification is needed.

> One could argue that a certificate that limits the scope of the certificate
> via name constraints can offer the same capability in that if the name form
> that the scenario is dependent on is bound to the scope specified in the
> name constraint they can not issue that certificate.

I would argue so. Furthermore, a CA is trusted, and as such will not issue certificates the customer did not allow. Else, the CA is not trusted, a flag in some intermediate certificate will not help.

> While it is generally true there are cases where it is not, for example
> where a web-server certificate should contain a contact email address.

In this case, the email address would not be just a contact, but part of the entity identified by the certificate. I am not sure that it is meaningful. Furthermore, the same key should not be used for several purposes. In general, I do not see real use cases for restricting the Extended key usage.
You need to log in before you can comment on or make changes to this bug.