Subject: RE: EKU ambiguity in RFC 3280

From: "Stefan Santesson" <[email-masked]>
Date: Tue, 2 Aug 2005 14:12:18 +0100

Are what you say that presence of anyEKU just allows an application who
don't care about EKUs to ignore the EKU extension content? 

That is, that anyEKY is never considered a match when a specific EKU is
required in a certificate?

I could live with that, it just needs to be said more clearly.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: Jim Schaad [mailto:[email-masked]]
> Sent: den 2 augusti 2005 05:11
> To: Stefan Santesson; 'pkix'
> Subject: RE: EKU ambiguity in RFC 3280
> 
> 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
> >
> >
> >
> > 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: Russ Housley <[email-masked]>
Date: Tue, 02 Aug 2005 13:14:12 -0400

I agree with this interpretation.  This is what is meant by:

    Certificate using applications MAY require that a particular purpose
    be indicated in order for the certificate to be acceptable to that 
application.

Such applications can reject a certificate for their use if the expected 
EKU value is not present, even if the anyEKU OID is present.

Russ

---

From: Sam Hartman <[email-masked]>
Date: Wed, 03 Aug 2005 03:18:08 -0400

>>>>> "Russ" == Russ Housley <[email-masked]> writes:

    Russ> Such applications can reject a certificate for their use if
    Russ> the expected EKU value is not present, even if the anyEKU
    Russ> OID is present.

Such applications would presumably require the EKU to be present too.