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 >
- Re: Key Usage Clarification in PKIX part 1 Housley, Russ
- Re: Key Usage Clarification in PKIX part 1 Trevor Freeman
- Re: Key Usage Clarification in PKIX part 1 Tom Weinstein
- Re: Key Usage Clarification in PKIX part 1 Mike Smith
- Key Usage Clarification in PKIX part 1 Trevor Freeman