Subject: RE: ExtendedKeyUsage for TLS Client Authentication

From: "Stefan Santesson" <[email-masked]>
Date: Thu, 22 Sep 2005 10:42:44 +0100

Johannes,

I have to correct myself slightly.

Microsoft IE and IIS do enforce EKU and the presence of the clientAuth
EKU when the EKU extension is present. When no EKU extension is present
the certificate is good for all usages and will as such also be
accepted.

When or not it is appropriate to include an EKU extension with usage
restrictions is up to the implementation dependent on your need to
distinguish different types of certificates.

I'll reply/comment further in-line;

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: Johannes Merkle [mailto:[email-masked]]
> Sent: den 21 september 2005 15:31
> To: [email-masked]
> Cc: Stefan Santesson; Peter Gutmann
> Subject: Re: ExtendedKeyUsage for TLS Client Authentication
> 
> Thank you Stefan
> 
> > At least Microsoft implementations do enforce both key usage and
> > extended key usage. For TLS client side authentication, the
clientAuth
> > EKU is required.
> So, IE and IIS only accept client certificates having the EKU
> clientAuth?
> 

[Stefan] As stated above. clientAuth is enforced if the EKU extension is
present.

> 
> > To achieve best possible interoperability, I would suggest always
> > including the clientAuth EKU in these certs.
> The problem is that EKU is restrictive, i.e. the certificate MUST
> only be used for those purposes indicated in the EKU. Now consider a
> case where a class of certifiates should be usable for many purposes
> including TLS, e-mail and document signing. Considering your
> statement I should include the EKUs clientAuth AND
> AnyExtendedKeyUsage, right? (I know that using a certifivcate for
> different application types can be poblematic. However, we only aim
> at a medium security level.)
> 

[Stefan] As I said, no EKU extension will work. However, AnyEKU may not
do the job for you since I don't think many implementations make use of
the anyEKU as the special case it is designed for. The current
definition of anyEKU is correct but in my mind a bit unclear. Unlike the
special policy anyPolicy which is a direct mapping against any specific
certificate policy, the anyEKU OID does not provide that type of generic
mapping. It only allows a client at its own discretion to disregard from
the presence of the EKU extension and accept the certificate for all
usages. An application that requires a specific EKU to be present may
not accept anyEKU as substitution. An example of this is how the current
PKINIT draft in Kerberos is formulated, where anyEKU is not accepted as
a substitution in cases where the Kerberos EKU is enforced.

> 
> Stefan, does Microsoft Outlook analogously require the EKU
> emailProtection?
> 
[Stefan] the emailProtection EKU is required if an EKU extension is
present. An absent EKU extension will also work.

> Stefan,
> 
> at which point would a certificate without EKU clientAuth fail? When
> selecting it with IE or when validating it at an IIS?
>

[Stefan] A certificate with a (presumed non empty) EKU extension with
absent clientAuth EKU will fail in both IE and IIS. In IE it will not be
selected and will not be shown in the certificate selection dialogue. If
used by any client anyway, it will not be accepted by IIS.

I hope this clarifies things.

/Stefan