Subject: [pkix] Ambiguity in 5280 Regarding EKU Processing During Certification Path Processing

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 28 Oct 2009 11:48:09 -0400

I am having some trouble deciding on how to interpret 5280 when extended
key usage appears in the CA certificates.

This is not a hypothetical scenario.  It has actually happened.  That
said, I am not sure how the vendor product actually behave (i.e., I have
not come across convincing test results).

I have come across the following interpretations from myself (who does
not cut code) and from folks who write PK enablement code as open source
or who are commercial vendors.

1. My interpretation: EKU in the trust anchor and in intermediate
certificates in certification paths should be ignored.

2. Open Source Developer Viewpoint: The path validation engine is EKU
unaware and thus ignores non-critical EKU and rejects the path when EKU
is marked critical.

3. Commercial Vendor Viewpoint: If EKU is present in the certificates in
the path, it needs to be valid for the purpose end certificate will be
used for.

4. Yet Another Interpretation: If EKU is present in the certificates in
the path, it must be valid for the purpose (albeit, there is no
particular defined EKU purpose for certificate or CRL signing and hence
the certificate will be rejected unless anyExtendedKeyUsageKeyPurposeId
is present).

Some of the above can have variations if anyExtendedKeyUsageKeyPurposeId
is present.

In short, different people have different interpretation of 5280 in this
regard and will give different path validation results.

Some clarity may be required.

My thinking is that RFC 5280 should do the following:

1. Requiring CA certificates not contain any EKU.  (My reading of 2560
is that a CA does not need OCSPSigning EKU for signing OCSP responses
and this constraint requires CA to use another key for time stamp
signing which is a good security practice).

2. Requiring compliant consumers to recognize and ignore EKU in
intermediate certificates in the certification path.

An alternative is of-course that all of the above are valid
interpretations.

Santosh Chokhani
CygnaCom Solutions

---

From: Thomas Pornin <[email-masked]>
Date: Wed, 28 Oct 2009 17:43:05 +0100

> key usage appears in the CA certificates.

What I understand from RFC 5280 is that:

When the EKU extension is present, then the certificate shall be used
only in contexts consistent with that extension. In particular, using
the certificate as a CA for path validation means that the EKU shall
feature the OID which designates such usage (somehow similar to the Key
Usage "keyCertSign"). RFC 5280 defines no such OID. Therefore, if a CA
certificate includes an EKU extension and that extension does not
include the special anyExtendedKeyUsage OID, then a conforming path
validator shall reject any path using that certificate as an
intermediate CA.

As usual, trust anchors encoded as certificates are a quite distinct
issue. In RFC 5280, trust anchors are pairs "DN + public key" and have
no extension per se. Whatever semantics can be attached to a TA when
that TA is stored with the encoding format of an X.509 certificate are
out of scope of RFC 5280.

> the certificate will be rejected unless anyExtendedKeyUsageKeyPurposeId

Only interpretation 4 is valid, in my opinion. Now, I so happen to have
developped some code which applies interpretation 1, and I am quite
happy with it: basically, a certificate with Basic Constraints stating
that this is a CA certificate, but with an EKU extension which prohibits
usage of the certificate within a certificate path, would make little
sense. Hence, using interpretation 1 does not seem to induce any
security weakness; thus, I am ready to consider it as "practically
valid" even though the letter of RFC 5280 forbids it.

Interpretation 2 uses the gimmick "if non-critical then you can ignore
it" which, as far as I can tell, is forbidden by RFC 5280 (the first
paragraph of section 4.2 states that "a non-critical extension MAY be
ignored if it is not recognized, but MUST be processed if it is
recognized."). Interpretation 3 looks like a confusion between EKU and
Certificate Policies, and it does not seem to be sanctioned in any way
by RFC 5280.

	--Thomas Pornin

---

From: "Carl Wallace" <[email-masked]>
Date: Wed, 28 Oct 2009 13:17:25 -0400

Inline...

<snip>
> out of scope of RFC 5280.
 
This echoes Denis' request for a usage field in trust anchors.  We may
need a new extension to express usage with rules that apply to the
entire path.  Likewise Denis' request for enforcement of TA validity
fields.  An extension that defined processing rules would likely be
required.
 
<snip>
> Certificate Policies, and it does not seem to be sanctioned in any way

Regarding option 2, section 6.1.5 (f) only requires non-critical
extensions that are "relevant to path processing" to be recognized and
processed.  Does EKU qualify?

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 28 Oct 2009 14:12:16 -0400

Santosh,

I think it is clear in RFC 5280 that interpretation 4 ("Yet Another 
Interpretation") is the correct one. [Of course, 2 is also valid as it 
simply specifies the general rule for handling an unrecognized 
extension.]  RFC 5280 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.

   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.

Given this text, it seems clear the the set of purposes applies to the 
subjectPublicKey in the certificate that contains the extKeyUsage 
extension, not the target (end entity) certificate in a certification 
path.  To read this as stating that it applies to the subjectPublicKey 
in the target certificate, the final paragraph would only make sense if 
the keyUsage extension also applied to the subjectPublicKey in the 
target certificate rather than the certificate containing the extension, 
and no one has claimed that the keyUsage extension doesn't specify 
acceptable uses for the subjectPublicKey in the certificate that 
contains the keyUsage extension. [I understand that there is a 
commercial vendor that has implemented interpretation 3, but I see no 
support for that interpretation in the text describing the extension.]

The text further supports this by saying that the extension will 
generally only appear in entity entity certificates, which would not 
make sense if the extension could be placed in a CA certificate to limit 
the purposes for which the target certificates subjectPublicKey could be 
used.

The text is also clear that the extension cannot be simply ignored if it 
appears in a CA certificate. I understand that many implementers will 
choose to simply ignore the extension since the alternative would be to 
conclude that the certificate cannot be used as an intermediate 
certificate.  While the standard states that the certificate cannot be 
used unless the purpose is consistent with both the keyUsage and 
extKeyUsage extensions, implementers are likely to conclude that a 
certificate with a basicConstraints extension with cA=TRUE and a 
keyUsage extension with keyCertSign asserted was intended by the issuer 
to be usable as an intermediate certificate even if the extKeyUsage 
extension indicates that it cannot be used for that purpose.  But, that 
would be the implementer choosing to ignore the standard in order to 
make a best guess as to how to process a certificate that contains 
contradictory information.  [This all assumes, of course, that no one 
defines an extended key usage OID that specifies verifying signatures on 
certificates as a purpose covered by the OID.]

I can only guess at why some issuers are placing an extKeyUsage 
extension in CA certificates, but I doubt that the decision was made 
based on a reading of RFC 5280 (or X.509).  One may choose to ignore the 
extension in order to be able to accept certificates that were issued 
with contradictory information in them, but such processing would be 
contrary to the standard.

Dave

---

From: Russ Housley <[email-masked]>
Date: Wed, 28 Oct 2009 15:15:58 -0400

Santosh:

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

>  the certificate will be rejected unless anyExtendedKeyUsageKeyPurposeId

Russ

---

From: "Timothy J. Miller" <[email-masked]>
Date: Wed, 28 Oct 2009 15:01:53 -0500

I think the consensus (which I concur with) is "don't do that, that's 
{bad,stupid}."  (4) seems the right answer.

-- Tim

Santosh Chokhani wrote:
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 28 Oct 2009 17:12:06 -0400

David (and, Russ, Tim and Thomas),

The support I see for option 4 is item O in Section 6.1.4 of 5280 and it
states:

"Recognize and process any other critical extension present in the
certificate.  Process any other recognized non-critical extension
present in the certificate that is relevant to path
processing."

Assuming we call EKU "relevant to path processing", option 2 result
which depends on criticality is also valid for the EKU unaware path
validation engines.

> -----Original Message-----
> From: David A. Cooper [mailto:[email-masked]] 
> Sent: Wednesday, October 28, 2009 2:12 PM
> To: Santosh Chokhani
> Cc: [email-masked]
> Subject: Re: [pkix] Ambiguity in 5280 Regarding EKU 
> Processing During Certification Path Processing
> 
> Santosh,
> 
> Interpretation") is the correct one. [Of course, 2 is also 
> valid as it simply specifies the general rule for handling an 
> unrecognized extension.]  RFC 5280 says:
> 
> Given this text, it seems clear the the set of purposes 
> applies to the subjectPublicKey in the certificate that 
> contains the extKeyUsage extension, not the target (end 
> entity) certificate in a certification path.  To read this as 
> stating that it applies to the subjectPublicKey in the target 
> certificate, the final paragraph would only make sense if the 
> keyUsage extension also applied to the subjectPublicKey in 
> the target certificate rather than the certificate containing 
> the extension, and no one has claimed that the keyUsage 
> extension doesn't specify acceptable uses for the 
> subjectPublicKey in the certificate that contains the 
> keyUsage extension. [I understand that there is a commercial 
> vendor that has implemented interpretation 3, but I see no 
> The text further supports this by saying that the extension 
> will generally only appear in entity entity certificates, 
> which would not make sense if the extension could be placed 
> in a CA certificate to limit the purposes for which the 
> target certificates subjectPublicKey could be used.
> 
> The text is also clear that the extension cannot be simply 
> ignored if it appears in a CA certificate. I understand that 
> many implementers will choose to simply ignore the extension 
> since the alternative would be to conclude that the 
> certificate cannot be used as an intermediate certificate.  
> While the standard states that the certificate cannot be used 
> unless the purpose is consistent with both the keyUsage and 
> extKeyUsage extensions, implementers are likely to conclude 
> that a certificate with a basicConstraints extension with 
> cA=TRUE and a keyUsage extension with keyCertSign asserted 
> was intended by the issuer to be usable as an intermediate 
> certificate even if the extKeyUsage extension indicates that 
> it cannot be used for that purpose.  But, that would be the 
> implementer choosing to ignore the standard in order to make 
> a best guess as to how to process a certificate that contains 
> contradictory information.  [This all assumes, of course, 
> that no one defines an extended key usage OID that specifies 
> verifying signatures on certificates as a purpose covered by the OID.]
> 
> I can only guess at why some issuers are placing an 
> extKeyUsage extension in CA certificates, but I doubt that 
> the decision was made based on a reading of RFC 5280 (or 
> X.509).  One may choose to ignore the extension in order to 
> be able to accept certificates that were issued with 
> contradictory information in them, but such processing would 
> be contrary to the standard.
> 
> Dave
> 
> Santosh Chokhani wrote:

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 29 Oct 2009 12:31:16 +0100

Santosh and all,

The problem is bigger than this.
EKU processing in CA certificates is one of the few major disconnects
between theory and reality that has survived from the early days of using
PKI for web server certificates and code-signing, which is very unlikely to
go away, no matter what we write in the standard.

This is fully comparable with the practice to put DNS names in the common
name field in server certificates which is highly discouraged, but still in
common use.

The background of the EKU issue is that EKU has been used for a very long
time to restrict the use of root certificates (trust anchors).
When a root certificate is approved for example in the Microsoft root store
as a code signing certificate, then it will either be issued with a
code-signing EKU in an EKU extension, or more commonly will be given a
code-signing EKU property. The EKU property is stored as metadata in the
root store and is not present in the root certificate.

The EKU property of the trust anchor is then used like an initial policy set
comparable to how certificate policies are processed in a path.

1) If the CA certificate has an absent EKU extension, the valid set of EKUs
from the root is unchanged.

2) If the CA certificate contains a set of EKUs, then the valid set is
reduced to the intersection of EKU property from the root and the EKUs of
the CA certificate.

Finally, the set of valid EKU's of the last certificate of the path is
reduced to the set allowed by the path (root property and CA certificates).

This mechanism is used to prevent a certificate with a code-signing EKU to
be accepted as a code signing certificate unless the code-signing EKU
property has been set for the trust anchor.

This has been a known disjoint between practice and theory for many years
and I even brought it up in the initial revision discussions of RFC 3280,
but was convinced that it was not worth the effort to try to bring reality
and theory together in this case. I can neither imagine that we will change
RFC 5280 to accommodate this practice, nor can I imagine that this practice
of using EKU will go away in any foreseeable future.

/Stefan

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 29 Oct 2009 17:43:14 -0400

Stefan,

Has this been tested and confirmed?

I ask because I thought what you describe below is  done by using
"application policies" extension that is private to Microsoft.

If CAPI is doing what you describe, that clearly is not in compliance
with X.509 or 5280.

> From: Stefan Santesson [mailto:[email-masked]] 
> Sent: Thursday, October 29, 2009 7:31 AM
> To: Santosh Chokhani; David A. Cooper
> Cc: [email-masked]
> EKU processing in CA certificates is one of the few major 
> disconnects between theory and reality that has survived from 
> the early days of using PKI for web server certificates and 
> code-signing, which is very unlikely to go away, no matter 
> what we write in the standard.
> 
> This is fully comparable with the practice to put DNS names 
> in the common name field in server certificates which is 
> highly discouraged, but still in common use.
> 
> The background of the EKU issue is that EKU has been used for 
> a very long time to restrict the use of root certificates 
> (trust anchors).
> When a root certificate is approved for example in the 
> Microsoft root store as a code signing certificate, then it 
> will either be issued with a code-signing EKU in an EKU 
> extension, or more commonly will be given a code-signing EKU 
> property. The EKU property is stored as metadata in the root 
> store and is not present in the root certificate.
> 
> The EKU property of the trust anchor is then used like an 
> initial policy set comparable to how certificate policies are 
> processed in a path.
> 
> 1) If the CA certificate has an absent EKU extension, the 
> valid set of EKUs from the root is unchanged.
> 
> 2) If the CA certificate contains a set of EKUs, then the 
> valid set is reduced to the intersection of EKU property from 
> the root and the EKUs of the CA certificate.
> 
> Finally, the set of valid EKU's of the last certificate of 
> the path is reduced to the set allowed by the path (root 
> property and CA certificates).
> 
> This mechanism is used to prevent a certificate with a 
> code-signing EKU to be accepted as a code signing certificate 
> unless the code-signing EKU property has been set for the 
> trust anchor.
> 
> This has been a known disjoint between practice and theory 
> for many years and I even brought it up in the initial 
> revision discussions of RFC 3280, but was convinced that it 
> was not worth the effort to try to bring reality and theory 
> together in this case. I can neither imagine that we will 
> change RFC 5280 to accommodate this practice, nor can I 
> imagine that this practice of using EKU will go away in any 
> foreseeable future.
> 
> 
> /Stefan
> 
> 
> 
> 
> 
> 
> 
> > The support I see for option 4 is item O in Section 6.1.4 
> of 5280 and 
> > it
> > states:
> > 
> > present in the certificate that is relevant to path processing."
> > 
> valid as 
> >> it simply specifies the general rule for handling an unrecognized 
> >> Given this text, it seems clear the the set of purposes applies to 
> >> the subjectPublicKey in the certificate that contains the 
> extKeyUsage 
> >> extension, not the target (end
> >> entity) certificate in a certification path.  To read this 
> as stating 
> >> that it applies to the subjectPublicKey in the target certificate, 
> >> the final paragraph would only make sense if the keyUsage 
> extension 
> >> also applied to the subjectPublicKey in the target 
> certificate rather 
> >> than the certificate containing the extension, and no one 
> has claimed 
> >> that the keyUsage extension doesn't specify acceptable 
> uses for the 
> >> subjectPublicKey in the certificate that contains the keyUsage 
> >> extension. [I understand that there is a commercial vendor 
> that has 
> >> implemented interpretation 3, but I see no support for that 
> >> interpretation in the text describing the extension.]
> >> 
> >> make sense if the extension could be placed in a CA certificate to 
> >> limit the purposes for which the target certificates 
> subjectPublicKey 
> >> could be used.
> >> 
> ignored if 
> >> it appears in a CA certificate. I understand that many 
> implementers 
> >> will choose to simply ignore the extension since the alternative 
> >> would be to conclude that the certificate cannot be used as an 
> >> intermediate certificate.
> >> While the standard states that the certificate cannot be 
> used unless 
> >> the purpose is consistent with both the keyUsage and extKeyUsage 
> >> extensions, implementers are likely to conclude that a certificate 
> >> with a basicConstraints extension with cA=TRUE and a keyUsage 
> >> extension with keyCertSign asserted was intended by the 
> issuer to be 
> >> usable as an intermediate certificate even if the extKeyUsage 
> >> extension indicates that it cannot be used for that purpose.  But, 
> >> that would be the implementer choosing to ignore the standard in 
> >> order to make a best guess as to how to process a certificate that 
> >> contains contradictory information.  [This all assumes, of course, 
> >> based on a reading of RFC 5280 (or X.509).  One may choose 
> to ignore 
> >> the extension in order to be able to accept certificates that were 
> >> issued with contradictory information in them, but such processing 
> >> would be contrary to the standard.
> >> 
> >> Dave
> >> 
> >> Santosh Chokhani wrote:

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 30 Oct 2009 02:35:44 +0100

Santosh,

I have personally tested and documented this functionality.
Application policy did indeed also have this path processing functionality,
but it's use was deprecated long ago.

Information about EKU processing (referred to as usage policy and Enhanced
Key Usage in many Microsoft documents) parameters as part of the
CertGetCertificateChain API call in CAPI is available from msdn:
http://msdn.microsoft.com/en-us/library/aa377593(VS.85).aspx

This is not so clearly explained on this page, but the choice of AND or OR
logic decides whether AND or OR logic is applied to the EKU path processing.
The OR logic was used when one could expect a mix of old Netscape OIDs and
new standardized OIDs for e.g. ServerAuth EKU.

If I recall the history correctly, the use of EKU for this purpose was
initiated by Netscape and Microsoft simply followed suit.

This is indeed not in compliance with X.509 nor 5280. In this case the
functionality as such has been regarded as more important than strict
standards compliance.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 30 Oct 2009 03:14:56 +0100

It strikes me that the following may require some more explanation.

> new standardized OIDs for e.g. ServerAuth EKU.

Setting the AND or OR logic is done in the CAPI API call (CERT_CHAIN_PARA
http://msdn.microsoft.com/en-us/library/aa377186(VS.85).aspx ) in the
following context:

Ex 1. EKU A AND EKU B
The target certificate is valid IF EKU A AND EKU B are supported by every
certificate in the path (either by explicit EKU setting or through absent
EKU extension in CA certificates)

Ex 2. EKU A OR EKU B
The target certificate is valid IF EKU A OR EKU B is supported by the path.

The OR test case is a bit special. To explain further, the OR test is deemed
valid in the following path:

Root: EKU property supports EKU A
CA 1: absent EKU extension
CA 2: EKU B in EKU extension
CA 3: EKU A in EKU extension
EE cert: EKU A in EKU extension

The use of the EE certificate is valid for EKU A in this case since the
request to the CAPI API asked that the certificate should be valid IF each
certificate of the path support either EKU A OR EKU B.

Now this may look extremely strange but the explanation has a grain of
logic. If EKU A and EKU B are two separate OIDs for the same usage, then the
certificate would be valid if each certificate of the path supported either
of the two valid EKUs.

Asking CAPI to validate the same path, requesting support for EKU A AND EKU
B would fail in the the example above, as that would require EKU A AND EKU B
to be supported by all certificates of the path.

/Stefan

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 29 Oct 2009 22:28:55 -0400

Stefan,

What is throwing monkey wrench in this, is that in addition to being
non-compliant to standards in processing EKU, CAPI does not honor
anyExtendedKeyUsage either.  Thus, for CAPI to succeed, you better not
put EKU in CA certificates.

> Sent: Thursday, October 29, 2009 10:15 PM
> To: Stefan Santesson; Santosh Chokhani; David A. Cooper
> Cc: [email-masked]
> > This is not so clearly explained on this page, but the 
> choice of AND 
> > or OR logic decides whether AND or OR logic is applied to 
> the EKU path processing.
> > The OR logic was used when one could expect a mix of old 
> Netscape OIDs 
> > and new standardized OIDs for e.g. ServerAuth EKU.
> 
> 
> http://msdn.microsoft.com/en-us/library/aa377186(VS.85).aspx 
> ) in the following context:
> 
> Ex 1. EKU A AND EKU B
> The target certificate is valid IF EKU A AND EKU B are 
> supported by every certificate in the path (either by 
> explicit EKU setting or through absent EKU extension in CA 
> certificates)
> 
> Ex 2. EKU A OR EKU B
> The OR test case is a bit special. To explain further, the OR 
> test is deemed valid in the following path:
> 
> The use of the EE certificate is valid for EKU A in this case 
> since the request to the CAPI API asked that the certificate 
> should be valid IF each certificate of the path support 
> either EKU A OR EKU B.
> 
> Now this may look extremely strange but the explanation has a 
> grain of logic. If EKU A and EKU B are two separate OIDs for 
> the same usage, then the certificate would be valid if each 
> certificate of the path supported either of the two valid EKUs.
> 
> Asking CAPI to validate the same path, requesting support for 
> EKU A AND EKU B would fail in the the example above, as that 
> would require EKU A AND EKU B to be supported by all 
> certificates of the path.
> 
> 
> /Stefan 
> 
> 
>

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 30 Oct 2009 03:59:44 +0100

Santosh,

What you say about anyEKU (anyExtendedKeyUsage) is not entirely true.

CAPI does support anyEKU in a compliant manner, but it turns the decision
over to the client (as it should).

It is important to understand in this context that anyEKU is fundamentally
different from anyPolicy in policy processing.

anyPolicy is a direct substitution for any policy OID in path processing,
anyEKU is not. anyEKU just allows the client to accept a certificate for
other usages than those explicitly specified by present EKUs.

This is allowed and supported by CAPI.

Example: If the application asks CAPI to check if the EE certificate support
EKU A, and the certificate does not support EKU A but does support anyEKU,
then this test will fail, saying that the certificate does not match the
requested usage.

This is correct since anyEKU does NOT mean that there is a match.

RFC 5280:  
  "Applications that require the presence of a
   particular purpose MAY reject certificates that include the
   anyExtendedKeyUsage OID but not the particular OID expected for the
   application."

In this case it is up to the application to subjectively accept anyPolicy as
a substitution for EKU A. In order to do this, the application should ask
CAPI if the EE certificate supports EKU A OR anyEKU. CAPI would honor this
in a 5280 compliant manner.

Further. This whole EKU issue is a non problem if CA certificates does not
contain EKUs. If EKUs are absent in the CA certificates, the EKU processing
of CPI turns fully standards compliant. The rarity of EKUs in CA
certificates is the reason why this mostly has passed unnoticed.

One could say that CAPI has its own way to interpret the meaning of EKU in
CA certificates in addition to standards compliant EKU processing.

On your closing point - I fully agree. One should not put EKUs in CA
certificates if you want consistent processing cross platforms.

/Stefan

---

From: Nelson B Bolyard <[email-masked]>
Date: Thu, 29 Oct 2009 20:53:54 -0700

On 2009-10-29 04:31 PDT, Stefan Santesson wrote:

> The background of the EKU issue is that EKU has been used for a very
> long time to restrict the use of root certificates (trust anchors). When
> a root certificate is approved for example in the Microsoft root store as
> a code signing certificate, then it will either be issued with a 
> The EKU property of the trust anchor is then used like an initial policy
> set comparable to how certificate policies are processed in a path.
> 
> 1) If the CA certificate has an absent EKU extension, the valid set of 
> EKUs from the root is unchanged.
> 
> reduced to the intersection of EKU property from the root and the EKUs
> of the CA certificate.
> 
> This mechanism is used to prevent a certificate with a code-signing EKU 
> to be accepted as a code signing certificate unless the code-signing EKU 

It also allows a root to designate an intermediate CA issuer as being
only capable of issuing (say) email certificates but neither TLS server
nor code signing certificates.

Netscape browsers also implemented that logic, as do Firefox browsers now
in the open source NSS libraries.

> This has been a known disjoint between practice and theory for many
> years and I even brought it up in the initial revision discussions of RFC
> 3280, but was convinced that it was not worth the effort to try to bring
> reality and theory together in this case. I can neither imagine that we
> will change RFC 5280 to accommodate this practice, nor can I imagine 
> that this practice of using EKU will go away in any foreseeable future.

and he wrote:

> The OR logic was used when one could expect a mix of old Netscape OIDs 

That matches my recollection too. I think it served a commonly perceived need.

> functionality as such has been regarded as more important than strict 

The RFC 5280 model seems to be that all root and intermediate CAs are
trusted to issue certs for all purposes, and constraints on usages are
only placed on EE certs.  IMO, and in the opinion of many others, that's
not an acceptable model.  For one thing, it doesn't let a CA limit its
liability from a subordinate CA or RA.

IMO, the perceived need is for a *standard* for hierarchical
application-oriented usage constraints, perhaps similar to name constraints,
that act upon standardized application objects, similar to EKU OIDs.  If a
CA can
constrain its subordinates' name spaces, why not also constrain their
application spaces?

I've been told that Certificate Policies extensions were supposed to
address these needs, but it appears to me that they haven't.  For one
thing, there's certainly no standardized set of certificate policy OIDs
for policies constraining application usages.

Until some standard explicitly addresses that perceived need, I suspect
we'll continue to live with the present non-standard scheme that Microsoft
and Firefox share.

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 30 Oct 2009 22:03:15 +1300

Stefan Santesson <[email-masked]> writes:

>Now this may look extremely strange

Always reassuring to see something like that in systems that people are
relying on to make critical security decisions :-).

(This is meant not specifically as a comment on CAPI's handling, but on the
general confusion over what happens when you put EKUs in certs).

Peter.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 30 Oct 2009 12:40:00 -0400

Nelson,

If folks think that a capability is required, they should use the
following means:

1.  Use private OID; or

2.  Follow the standards process to add a new extension.

It is inappropriate to ascribe additional, less, or different semantics
to a standard OID and it meaning.

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Nelson B Bolyard
> Sent: Thursday, October 29, 2009 11:54 PM
> To: [email-masked]
> > long time to restrict the use of root certificates (trust anchors). 
> Microsoft root 
> > store as a code signing certificate, then it will either be issued 
> > with a code-signing EKU in an EKU extension, or more 
> commonly will be 
> > given a code-signing EKU property. The EKU property is stored as 
> > metadata in the root store and is not present in the root 
> certificate.
> > 
> > The EKU property of the trust anchor is then used like an initial 
> > policy set comparable to how certificate policies are 
> processed in a path.
> > 
> valid set is 
> the path is 
> > This mechanism is used to prevent a certificate with a code-signing 
> > EKU to be accepted as a code signing certificate unless the 
> > code-signing EKU property has been set for the trust anchor.
> 
> It also allows a root to designate an intermediate CA issuer 
> as being only capable of issuing (say) email certificates but 
> neither TLS server nor code signing certificates.
> 
> Netscape browsers also implemented that logic, as do Firefox 
> browsers now in the open source NSS libraries.
> 
> > years and I even brought it up in the initial revision 
> discussions of 
> > RFC 3280, but was convinced that it was not worth the 
> effort to try to 
> > bring reality and theory together in this case. I can 
> neither imagine 
> > that we will change RFC 5280 to accommodate this practice, 
> nor can I 
> The RFC 5280 model seems to be that all root and intermediate 
> CAs are trusted to issue certs for all purposes, and 
> constraints on usages are only placed on EE certs.  IMO, and 
> in the opinion of many others, that's not an acceptable 
> model.  For one thing, it doesn't let a CA limit its 
> application-oriented usage constraints, perhaps similar to 
> name constraints, that act upon standardized application 
> objects, similar to EKU OIDs.  If a CA can constrain its 
> subordinates' name spaces, why not also constrain their 
> application spaces?
> 
> I've been told that Certificate Policies extensions were 
> supposed to address these needs, but it appears to me that 
> they haven't.  For one thing, there's certainly no 
> standardized set of certificate policy OIDs for policies 
> constraining application usages.
> 
> Until some standard explicitly addresses that perceived need, 
> I suspect we'll continue to live with the present 
> non-standard scheme that Microsoft and Firefox share.
>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 30 Oct 2009 12:46:48 -0400

All,

If this is getting into too much detail, I can carry out this as a
private communication with Stefan.  Let me know.

Stefan,

So, let us say that I have one or more CA certificates in a chain
asserting anyEKU and possibly one or more private EKU.

What is happening with respect to Outlook (+CAPI) or IIS (+CAPI) if the
end certificate does not have an EKU?

I ask because Outlook and IIS do not require secure e-mail or client
authentication EKU respectively in the end certificate.  They are happy
if none are present.

Is it the case that they ask CAPI what EKU you got and it says anyEKU
and they barf?  If CAPI said none, they will be happy????

> Sent: Thursday, October 29, 2009 11:00 PM
> CAPI does support anyEKU in a compliant manner, but it turns 
> the decision over to the client (as it should).
> 
> It is important to understand in this context that anyEKU is 
> fundamentally different from anyPolicy in policy processing.
> 
> anyPolicy is a direct substitution for any policy OID in path 
> processing, anyEKU is not. anyEKU just allows the client to 
> accept a certificate for other usages than those explicitly 
> specified by present EKUs.
> 
> Example: If the application asks CAPI to check if the EE 
> certificate support EKU A, and the certificate does not 
> support EKU A but does support anyEKU, then this test will 
> fail, saying that the certificate does not match the requested usage.
> 
> In this case it is up to the application to subjectively 
> accept anyPolicy as a substitution for EKU A. In order to do 
> this, the application should ask CAPI if the EE certificate 
> supports EKU A OR anyEKU. CAPI would honor this in a 5280 
> compliant manner.
> 
> 
> 
> Further. This whole EKU issue is a non problem if CA 
> certificates does not contain EKUs. If EKUs are absent in the 
> CA certificates, the EKU processing of CPI turns fully 
> standards compliant. The rarity of EKUs in CA certificates is 
> the reason why this mostly has passed unnoticed.
> 
> One could say that CAPI has its own way to interpret the 
> meaning of EKU in CA certificates in addition to standards 
> compliant EKU processing.
> 
> On your closing point - I fully agree. One should not put 
> EKUs in CA certificates if you want consistent processing 
> cross platforms.
> 
> 
> /Stefan
> 
> 
> 
> 
> supported by 
> >> every certificate in the path (either by explicit EKU setting or 
> >> through absent EKU extension in CA
> >> certificates)
> >> 
> >> Ex 2. EKU A OR EKU B
> >> The target certificate is valid IF EKU A OR EKU B is 
> supported by the 
> >> path.
> >> 
> >> 
> >> The OR test case is a bit special. To explain further, the 
> OR test is 
> >> deemed valid in the following path:
> >> 
> >> The use of the EE certificate is valid for EKU A in this 
> case since 
> >> the request to the CAPI API asked that the certificate should be 
> >> valid IF each certificate of the path support either EKU A 
> OR EKU B.
> >> 
> >> Now this may look extremely strange but the explanation 
> has a grain 
> >> of logic. If EKU A and EKU B are two separate OIDs for the same 
> >> usage, then the certificate would be valid if each 
> certificate of the 
> >> path supported either of the two valid EKUs.
> >> 
> >> Asking CAPI to validate the same path, requesting support 
> for EKU A 
> >> AND EKU B would fail in the the example above, as that 
> would require 
> >> EKU A AND EKU B to be supported by all certificates of the path.
> >> 
> >> 
> >> /Stefan
> >> 
> >> 
> >> 
> 
> 
>

---

From: "Timothy J. Miller" <[email-masked]>
Date: Fri, 30 Oct 2009 12:42:56 -0500

I wouldn't even go that far.  Attempting to restrict the end-entity 
issuing capability of a downstream CA is a pointless exercise because 
validation engines can ignore the restriction anyway.

-- Tim

---

From: Russ Housley <[email-masked]>
Date: Fri, 30 Oct 2009 15:22:34 -0400

>to a standard OID and it meaning.

I've said the same thing in the past.  This disconnect has been 
raised in the past.  Yet, no one has acted.  Clearly, no one cares 
enough to pick up the pen or change the code.

Russ

---

From: Tom Gindin <[email-masked]>
Date: Sat, 31 Oct 2009 17:42:15 -0400

EKU is NOT relevant to basic path processing, and isn't even 
mentioned in RFC 5280 section 6.  Any feature of a certificate can 
theoretically be defined as relevant to extended path processing by 
whoever defines the extension.  #2 seems like a sensible pragmatic choice, 
as does #1 - they'll only differ from #4 in accepting intermediate 
certificates which include an EKU (such as those written by the guy in 
#3).
        Do we need a general-purpose constraint extension of some sort? If 
so, how could one implement it?  EKU-Constraints would be easy enough to 
define (any certificate descending from an issuer containing 
EKU-constraints would be rejected if it contained any EKU outside the 
intersection of the EKU-constraints extensions actually present in 
certificates within its chain, with absence meaning ANY permitted), but 
would take years to get deployed.  The only bit in KeyUsage which I can 
see a reason to constrain in a similar way is NR (basicConstraints already 
constrains keyCertSign), and you'd need a special case for it (if 
no-NR-certs is contained in any EKU constraint extension in the path, any 
certificate with KeyUsage including NR is to be rejected).

Tom Gindin

P.S. - The opinions above are my own, and not necessarily those of my 
employer.

From:
"Santosh Chokhani" <[email-masked]>
To:
"David A. Cooper" <[email-masked]>
Cc:
[email-masked]
Date:
10/28/2009 05:12 PM
Subject:
Re: [pkix] Ambiguity in 5280 Regarding EKU Processing During Certification 
Path Processing
Sent by:
[email-masked]