Subject: EKU ambiguity in RFC 3280

From: "Stefan Santesson" <[email-masked]>
Date: Tue, 2 Aug 2005 11:04:16 +0100

I would like to raise an issue of potential ambiguity of the
specification of the EKU extension and the meaning of the anyEKU OID.

RFC 3280 states:
   If the extension is present, then the certificate MUST only be used
   for one of the purposes indicated.  If multiple purposes are
   indicated the application need not recognize all purposes indicated,
   as long as the intended purpose is present.  Certificate using
   applications MAY require that a particular purpose be indicated in
   order for the certificate to be acceptable to that application.

   If a CA includes extended key usages to satisfy such applications,
   but does not wish to restrict usages of the key, the CA can include
   the special keyPurposeID anyExtendedKeyUsage.  Conforming CAs SHOULD
   NOT mark this extension as critical if the anyExtendedKeyUsage
   keyPurposeID is present.

The statement of concern is:
   "Certificate using
   applications MAY require that a particular purpose be indicated in
   order for the certificate to be acceptable to that application."

The ambiguity is whether that requirement is satisfied by presence of
anyEKU in the certificate or not.

On one hand you could argue that this means that an application can
require that a specific EKU is explicitly listed (anyEKU would not be
enough), but on the other hand you could argue that the succeeding
paragraph defines the meaning of anyEKU to be equivalent to explicit
presence of all possible EKUs and thus would satisfy this requirement.

Compare with how we process certificate policies, where the special
policy anyPolicy actually satisfies requirement for any specific policy
in the path validation algorithm. That is, there is no way to specify
that a particular policy must be explicitly present and that anyPolicy
will not satisfy as substitution.

This issue became recently highlighted in the Kerberos WG where it was
suggested that the Kerberos PKINIT specification could require the
Kerberos EKU to be explicitly present but would not accept the anyEKU as
substitution.

The practical problem arises if EKU matching is performed by a standard
library which automatically match anyEKU to any specific EKU requested
for the certificate. Following the logic of the Kerberos logic it would
require that library to accept an argument that anyEKU matching should
be disabled, which adds complexity and introduces confusion.

At least I think this issue needs to be clarified in RFC 3280bis.

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 2 Aug 2005 14:10:53 +0200

Stefan,

It is my opionion that what the Kerbros working group wants is correct.  The
anyExtendedKeyUsage is provided so that one can place a specific EKU into a
certificate, but still allow the certificate to be used for other usages as
well.

jim 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stefan Santesson
> Sent: Tuesday, August 02, 2005 12:04 PM
> To: pkix
> Subject: EKU ambiguity in RFC 3280
> 
> 
> 
> The ambiguity is whether that requirement is satisfied by 
> presence of anyEKU in the certificate or not.
> 
> On one hand you could argue that this means that an 
> application can require that a specific EKU is explicitly 
> listed (anyEKU would not be enough), but on the other hand 
> you could argue that the succeeding paragraph defines the 
> meaning of anyEKU to be equivalent to explicit presence of 
> all possible EKUs and thus would satisfy this requirement.
> 
> Compare with how we process certificate policies, where the 
> special policy anyPolicy actually satisfies requirement for 
> any specific policy in the path validation algorithm. That 
> is, there is no way to specify that a particular policy must 
> be explicitly present and that anyPolicy will not satisfy as 
> substitution.
> 
> This issue became recently highlighted in the Kerberos WG 
> where it was suggested that the Kerberos PKINIT specification 
> could require the Kerberos EKU to be explicitly present but 
> would not accept the anyEKU as substitution.
> 
> The practical problem arises if EKU matching is performed by 
> a standard library which automatically match anyEKU to any 
> specific EKU requested for the certificate. Following the 
> logic of the Kerberos logic it would require that library to 
> accept an argument that anyEKU matching should be disabled, 
> which adds complexity and introduces confusion.
>