Subject: RE: ExtendedKeyUsage for TLS Client Authentication

From: "Stefan Santesson" <[email-masked]>
Date: Wed, 21 Sep 2005 14:17:07 +0100

Peter,

I think this is misleading advice.
At least Microsoft implementations do enforce both key usage and
extended key usage. For TLS client side authentication, the clientAuth
EKU is required. EKU is a widely deployed solution for certificate
purpose distinction and works pretty well.

To achieve best possible interoperability, I would suggest always
including the clientAuth EKU in these certs.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Peter Gutmann
> Sent: den 21 september 2005 08:21
> To: [email-masked]; [email-masked]
> Subject: Re: ExtendedKeyUsage for TLS Client Authentication
> 
> 
> Johannes Merkle <[email-masked]> writes:
> 
> >RFC 3280 defines the ExtendedKeyUsage clienthAuth for TLS client
> >authentication. However, it is not specified whether this
> >extendedKeyUsage is mandatory for TLS client certificates.
> >
> >Do clients and servers commonly require this extendedKeyUsage for
> >TLS client certificates or can it be omitted?
> 
> I've seen it appear in one or two certs from boutique CAs, but I'm not
> aware
> of anything that cares about it.  It's hard enough finding software
> that'll
> pay any attention to keyUsage values, let alone extKeyUsage.
> 
> In other words you can include or omit it as it suits you.
> 
> Peter.

---

From: Johannes Merkle <[email-masked]>
Date: Wed, 21 Sep 2005 15:30:33 +0200

Thank you Stefan

> EKU is required. 
So, IE and IIS only accept client certificates having the EKU
clientAuth?

> 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, does Microsoft Outlook analogously require the EKU
emailProtection?

Johannes

---

From: "Gregory S. Chudov" <[email-masked]>
Date: Wed, 21 Sep 2005 20:11:15 +0400

> So, IE and IIS only accept client certificates having the EKU
_IF_ the client certificate has EKU extension at all.
When this extension is not present, certificate is accepted.
I don't know of any TLS implementations that require its presence.

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 22 Sep 2005 23:59:39 +1200

"Stefan Santesson" <[email-masked]> writes:

>I think this is misleading advice. At least Microsoft implementations do
>enforce both key usage and extended key usage.

I thought CryptoAPI explicitly allowed signing with encryption-only keys or
encryption with signing-only keys (I'd have to look up the details of which
one it was)?  I've also had reports from users about it ignoring other usage
restrictions... some of this dates back a few years, so maybe it's gotten
better now.  OTOH it was only two years ago that CryptoAPI actually started
bothering to pay attention to the CA flag, and only then because of widespread
bad publicity.

(The reason why I made the comment was that cryptlib is very careful about
 enforcing key usage (and any other) constraints, and the probably single
 biggest set of user complaints that I get is from users saying that certs
 they've used for ages can't be used with cryptlib.  The result is invariably
 that they're trying to encrypt with a signature-only cert, or something
 similar.  Only about two weeks ago I got mail from a PKI application
 developer to say that cryptlib was the first PKI code he'd ever run into that
 recognised (and rejected) the use of a CA-cert/CRL-signature-only cert for
 data encryption).

Peter.