Re: Key Usage Clarification in PKIX part 1

Tom Weinstein <tomw@netscape.com> Wed, 09 April 1997 21:11 UTC

Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id OAA15231; Wed, 9 Apr 1997 14:11:49 -0700
Received: from netscape.com by suntan.tandem.com (8.6.12/suntan5.970212) for <ietf-pkix@tandem.com> id OAA15224; Wed, 9 Apr 1997 14:11:47 -0700
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id OAA12551 for <ietf-pkix@tandem.com>; Wed, 9 Apr 1997 14:11:15 -0700 (PDT)
Received: from troll ([206.222.233.75]) by dredd.mcom.com (Netscape Mail Server v2.02) with SMTP id AAA4015; Wed, 9 Apr 1997 14:11:13 -0700
Sender: tomw@netscape.com
Message-ID: <334C05F3.FF6@netscape.com>
Date: Wed, 09 Apr 1997 14:11:15 -0700
From: Tom Weinstein <tomw@netscape.com>
Organization: Netscape Communications, Inc.
X-Mailer: Mozilla 3.01 (X11; U; IRIX 6.2 IP22)
MIME-Version: 1.0
To: Trevor Freeman <trevorf@microsoft.com>
CC: "Pkix List (E-mail)" <ietf-pkix@tandem.com>
Subject: Re: Key Usage Clarification in PKIX part 1
References: <334B8F0C.3B1DCE0@netscape.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Trevor Freeman wrote:
> 
> Following yesterdays discussion with the SSL people, it would seem
> clear that some clarification on the meaning of the key usage types is
> required in pkix part 1.  I cannot see that when SSL performs a series
> of cryptographic transformation on some data in order to derive a
> symmetric algorithm session key, it is performing a digital signature.
> You cannot use DSA in this protocol.

This is not completely accurate.  There are a couple of modes in which
SSL can operate using only signing certificates.

One mode is where the server generates a temporary RSA key, which it
then signs and sends to the client.  The client verifies the signature
on the temporary key and then encrypts key exchange data with it.  The
server decrypts the data and they both generate session keys.  There's
a similar mode using Diffie-Hellman key exchange.  In all of these
cases, DSA can be used as the signing algorithm.

You can certainly argue that, even though it's using a signing
operation, the real use of the key is for a key exchange operation.

> Also SSL is performing what PKIX part 3 would describe as a direct
> proof of possession(POPO), that is they are establishing the binding
> between the public and private key pair. If the CA has a policy to
> ensure a strong binding between the public key and the user identity,
> then the application may also infer a authentication. The certificate
> consumers need to understand that if the CA has a weak binding between
> public key and identity, then the authentication is weak as any D Duck
> class 1 certificate would testify. They also need to understand that
> if the CA has a policy of issuing certificate with a weak binding
> between the public and private key(i.e. does not do a POPO of the key
> pair, as part of certificate creation), then when SSL does a POPO, it
> does not prove very much.

Yes, if the binding between the certificate and the identity is weak,
then so will any authentication performed with that certificate.  You
must always be careful about the policies of the CAs you trust.

-- 
You should only break rules of style if you can    | Tom Weinstein
coherently explain what you gain by so doing.      | tomw@netscape.com