Re: Extended Key Usage Extension

[Tim Dierks <[e-mail]>]

At 11:50 AM -0700 4/10/97, Warwick Ford wrote:
>id-kp-serverAuth			OBJECT IDENTIFIER	::=	{id-kp 1}
>-- TLS Web server authentication
>-- Key usage bits that may be consistent: keyEncipherment or keyAgreement
>id-kp-clientAuth			OBJECT IDENTIFIER	::=	{id-kp 2}
>-- TLS Web client authentication
>-- Key usage bits that may be consistent: digitalSignature

Warwick, thank you for this proposal.

First, the minor note: id-kp-serverAuth is also consistent with
digitalSignature, for modes in which the server signs an ephemeral RSA or
Diffie-Hellman key.

Also, it is my contention that it would be a good idea to provide values
for no-serverAuth and no-clientAuth as well. This is an issue that arises
because implementors need to interoperate with non-PKIX usage spaces and/or
would like flexibility in certificate use.

Specifically, let's say I am a TLS web client vendor. For interoperability
reasons and backwards compatibility, I would like to allow servers to use
X.509v1 certs and/or non-PKIX compliant X.509v3 certs. Since I cannot deny
access because id-kp-serverAuth isn't there, I can't keep PKIX compatible
clients (who I suggest should have no-serverAuth OIDs) from masquerading as
SSL servers.

You could battle this by marking the extension critical, but this would
lead to an undesirable lack of flexibility: when we introduce secure
telephony, one wouldn't be able to use a TLS client certificate for secure
telephony because it presumably wouldn't have an
id-kp-watsonComeHereINeedYou OID (which hadn't been invented when the cert
was signed), even though the policy and distinguished name of the
certificate might allow it.

On the other hand, I suppose that it would be bad to have to list all the
various things a certificate can't do, as well: id-kp-serverAuth,
id-kp-breakTheLaw, id-kp-enableDoomsdayDevice, etc.

 - Tim

Tim Dierks - [e-mail] - www.consensus.com
     Software Haruspex - Consensus Development
  Developer of SSL Plus: SSL 3.0 Integration Suite