Re: Extended Key Usage Extension

["Housley, Russ" <[e-mail]>]

Tim:

I do not like the idea of listing all of the thinks that a public key 
cannot be used to do.  Such a list is always incomplete.  Pleople will 
continute to invent applications and uses for public key cryptography.

Russ


______________________________ Reply Separator _________________________________
Subject: Re: Extended Key Usage Extension
Author:  Tim Dierks <[e-mail]> at internet
Date:    4/10/97 5:40 PM


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