EKU in intermediate certificates

[Kathleen Wilson]

This is in regards to item #10 of
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html

I have been getting questions about EKU in intermediate certificates,
the questions boil down to:


1) RFC 5280 reads "In general, this extension will appear only in end
entity certificates". So do not you think it's a bit non-standard to
have such extension in SubCA certificates?

Some applications might even choke on receiving a certificate chain
containing such an extension in a CA certificate.

Could you kindly send me, or help me find, a technically constrained
SubCA certificate?



2) We feel there is a conflict with the way Mozilla is interpreting EKU
and the intention of the EKU as defined in X.500 and RFC 5280. RFC5280
4.2.1.12 :
“In general, this extension will appear only in end entity certificates.
…
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.”

What EKU indicates the certificate can be used to sign certificates and
CRLs?


Let's discuss what the answers to these questions should be.


Thanks,
Kathleen

[Erwann Abalea]

Le vendredi 1 février 2013 17:59:08 UTC+1, Kathleen Wilson a écrit :
> This is in regards to item #10 of
> http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
>
> I have been getting questions about EKU in intermediate certificates,
> the questions boil down to:
>
> 1) RFC 5280 reads "In general, this extension will appear only in end
> entity certificates". So do not you think it's a bit non-standard to
> have such extension in SubCA certificates?

It is non standard, for sure. There's no standard way to express a constraint such as "the certificates under this CA can be used only for an S/MIME purpose", other than rely on certificatePolicies extension.

> 2) We feel there is a conflict with the way Mozilla is interpreting EKU
> and the intention of the EKU as defined in X.500 and RFC 5280. RFC5280
> 4.2.1.12 :
> “In general, this extension will appear only in end entity certificates.
> …
> 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.”

The corresponding text in ITU X.509 asks for this behavior if both extensions are set critical.

> What EKU indicates the certificate can be used to sign certificates and
> CRLs?

There's none.

[Ryan Hurst]

On Friday, February 1, 2013 8:59:08 AM UTC-8, Kathleen Wilson wrote:
> Some applications might even choke on receiving a certificate chain
>
> containing such an extension in a CA certificate.

Since Windows 95 Windows has behaved exactly the way the policy draft suggests NSS will work. The inclusion of EKUs in intermediate CAs has also been common for enterprise CAs since Windows has used this model as a means to constrain CAs since then.

Given the nearly two decade history of this practice in the most deployed client platform and the lack of customer complaints from it during my decade working at Microsoft in this area it seems the chances of this breaking any application by adopting the same behavior seems slim.

> Could you kindly send me, or help me find, a technically constrained
>
> SubCA certificate?
>

We have several customers with them but none of are are on the public internet from what I understand, here is a script I assembled that creates such certificates for testing you can look at - http://unmitigatedrisk.com/?p=194

>
> 2) We feel there is a conflict with the way Mozilla is interpreting EKU
>

> and the intention oof the EKU as defined in X.500 and RFC 5280. RFC5280

>
> 4.2.1.12 :
>
> “In general, this extension will appear only in end entity certificates.
>
> …
>
> 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.”
>
>
>
> What EKU indicates the certificate can be used to sign certificates and
>
> CRLs?
>
>

This is a legitimate concern relating to the lack of clarity in the RFCs relating to EKUs in CA certificates. As written one can interpret the RFCs to say EKUs can never be in CA certificates since there is no CRL or Certificate signing EKU even though inclusion of EKUs in CA certificates is "generally allowed".

My position would be that the RFCs need to be clarified to deal with the conflict.

With that said given the nearly two decades of this practice by the most used client in the world it still seems unlikely that Mozilla adopting the same behavior and mandating the usage of the practice in Enterprise subordination cases would break a client of significance -- if any.

I think the question boils down to "Should Mozilla adopt the same processing semantic as the Windows platform", I think the answer is dependent on if Mozilla sees value in enabling the subordination of an enterprise CA for enterprise specific usages without exposing the internet to additional SSL spoofing risks.

It seems to me that the value to the internet for adopting this behavior is fairly large, as such if I were Mozilla I think my answer to that question would be yes.

[Ryan Hurst]

It is also worth noting that Mozilla already implements this same logic with Object Signing according to this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=321156

And that OpenSSL also uses a very similar behavior for its sslserver EKU verification logic.

[Kathleen Wilson]

I started an FAQ regarding the new policy...

https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Frequently_Asked_Questions

Of course, the first item that I added is about EKU.

--
1. RFC 5280 reads "In general, this extension will appear only in end
entity certificates". Is it non-standard to have EKU in intermediate
certificates, and will client software break when receiving such a
certificate chain?
- Inclusion of EKU in CA certificates is generally allowed. NSS and
CryptoAPI both treat the EKU extension in intermediate certificates as a
constraint on the permitted EKU OIDs in end-entity certificates.
Browsers and certificate client software have been using EKU in
intermediate certificates, and it has been common for enterprise
subordinate CAs in Windows environments to use EKU in their intermediate
certificates to constrain certificate issuance. Therefore, it is
unlikely that using EKU in intermediate certificates would break other
client software.
- The use of the EKU extension in intermediate certificates was
discussed at length in the mozilla.dev.security.policy forum. We
considered other options, such as standardizing a set of Policy OIDs or
un-deprecating NetscapeCertType. The discussion included the concern
that one interpretation of RFC 5280 is that this use of EKU is
non-standard, but it was decided that the RFCs are not clear, and
perhaps conflicting, in regards to EKUs in CA certificates. In the
discussion it was pointed out that other major browsers and client
software already support this use of EKU but do not recognize
NetscapeCertType; and we also recognized the difficulties involved in
standardizing a set of Policy OIDs. The conclusion of the discussion was
that EKU is the best tool for technically constraining the types of
certificates that an intermediate certificate may sign.
--

Note that I also included a link to the discussion in
mozilla.dev.security.policy in which we decided to use EKU in this manner.
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/0jnELviAxxo



I will appreciate suggestions, clarifications, and corrections on this
FAQ response.

Thanks,
Kathleen