Re: Key Usage Clarification in PKIX part 1

"Housley, Russ" <housley@spyrus.com> Thu, 10 April 1997 23:14 UTC

Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id QAA17513; Thu, 10 Apr 1997 16:14:51 -0700
Received: from netcomsv.netcom.com by suntan.tandem.com (8.6.12/suntan5.970212) for <ietf-pkix@tandem.com> id QAA17500; Thu, 10 Apr 1997 16:14:46 -0700
Received: by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id NAA24530; Thu, 10 Apr 1997 13:17:44 -0700
Received: from cc:Mail by spysouth.spyrus.com id AA860699014 Thu, 10 Apr 97 12:03:34
Date: Thu, 10 Apr 1997 12:03:34 -0000
From: "Housley, Russ" <housley@spyrus.com>
Encoding: 3939 Text
Message-Id: <9703108606.AA860699014@spysouth.spyrus.com>
To: ietf-pkix@tandem.com, Trevor Freeman <trevorf@microsoft.com>
Subject: Re: Key Usage Clarification in PKIX part 1

The following text will be added to the document in the Key Usage section 
(4.2.1.3).  I hope this addresses the concerns.  If not, please post recommended
text changes.

  Russ

= = = = = = = = = =

The key usage extension defines the purpose (e.g., encipherment, signature, 
certificate signing) of the key contained in the certificate.  The usage 
restriction might be employed when a key that could be used for more than one 
operation is to be restricted.  For example, when an RSA key should be used only
for signing, the digitalSignature and nonRepudiation bits would be asserted.  
Likewise, when an RSA key should be used only for key management, the 
keyEncipherment bit would be asserted.  The profile recommends that when used, 
this be marked as a critical extension.

Bits in the KeyUsage type are used as follows:

   The digitalSignature bit is asserted when the subject public key is used 
   to verifying digital signatures that have purposes other than 
   non-repudiation, certificate signature, and CRL signature.  For example, 
   The digitalSignature bit is asserted when the subject public key is used 
   to provide authentication.
   
   The nonRepudiation bit is asserted when the subject public key is used 
   to verifying digital signatures used to provide a non-repudiation 
   service which protects against the signing entity falsely denying some 
   action, excluding certificate or CRL signing.
   
   The keyEncipherment bit is asserted when the subject public key is used 
   for key transport.  For example, when an RSA key is to be used 
   exclusively for key management, then this bit must asserted.
   
   The dataEncipherment bit is asserted when the subject public key is used 
   for enciphering user data, other than cryptographic keys.
   
   The keyAgreement bit is asserted when the subject public key is used for 
   key agreement.  For example, when a Diffie-Hellman key is to be used 
   exclusively for key management, then this bit must asserted.
   
   The keyCertSign bit is asserted when the subject public key is used for 
   verifying a signature on certificates.  This bit may only be asserted in 
   CA certificates.

   The cRLSign bit is asserted when the subject public key is used for verifying 
   a signature on CRLs.  This bit may only be asserted in CA certificates.



______________________________ Reply Separator _________________________________
Subject: Key Usage Clarification in PKIX part 1
Author:  Trevor Freeman <trevorf@microsoft.com> at internet
Date:    4/9/97 5:00 AM


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

Dr Trevor Freeman
Senior Consultant
Microsoft Consulting Services
Microsoft Ltd ECU
> Tel: UK(+44) 1734 270 412 
>