Re: Extended Key Usage Extension

[Warwick Ford <[e-mail]>]

Tim:

At 07:51 PM 4/9/97 -0500, Tim Dierks wrote:
>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.

OK.  Shall fix this.

>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.

As you and Russ both suggest, I don't think this would be practical.  Also,
I am not sure it is needed.  Basically, the CA has to decide if a
certificate is to be limited to a particular purpose or set of purposes
(for example, client authentication and S/MIME) - the CA will have decided
this in order to protect itself from possible risks if its certs are used
for other (envisaged or unenvisaged) purposes.  In this case, the CA should
flag the extended key usage extension critical.

If the CA is not so dogmatic, it can flag the extension noncritical.  In
this case it is up to the cert-using application to decide, on the basis of
information in the cert and other context information, whether or not to
use a cert.  So your TLS web client might, for example, decide to accept
any of the following cert types from a server:
 - a v3 cert with id-kp-serverAuth set;
 - a v3 cert with the appropriate bit set in a Netscape proprietary extension;
 - a v1 cert or v3 cert without the extended key usage extension (in which
case a warning message might be displayed to the user).
The client would expressly not use any cert with an extended key usage
extension without id-kp-serverAuth set, since this is clearly wrong.

>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

Warwick

---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [e-mail]; Tel: [phone] x225; Fax: [phone]
---------------------------------------------------------------------