RE: key usage - key encipherment or data encipherment

["Simon McMahon" <Simon_McMahon@xxxxxxxxxxxxxxxxx>]

Sorry but I think this new text is just more jargon and does not address the problem. The problem is that there are 2 bits for encryption instead of 1 so people can make a choice and need direction in that choice, but will still get it wrong anyway, just because they can (Murphy). The misunderstanding is that "keyEncipherment" is nearly always the correct choice but sometimes people use "dataEncipherment" because the transport keys are not explicit.

Note that a new definition of a public key cipher RSA' that internally used "RSA+AES" but didn't publish that fact could have RSA' public keys (not RSA keys but internally identical to them) that directly encrypt large amounts of data. The transport key just blends into the cipher text. "dataEncipherment" is then the correct bit for the RSA' key but I'll bet people who know its really RSA+AES will use "keyEncipherment" because that is what is really happening.

The bottom line is that this problem will never go away as long as you have two bits whose meanings overlap like these ones do. The bits should be merged because CA's that know about interoperability issues just set both anyway. I would prefer a consolidation these flags and to deprecate "dataEncipherment". That would leave "keyEncipherment" that could be renamed to "encipherment". Then there is no confusion because there is no choice anymore.

Anyway, back to the text...

Why did the "private" key creep into this description? "Private" keys are also "secret". By the way, how does a public key encrypt a private key? It is impossible, at least with RSA without a symmetric key in there, unless the private key is a lot smaller. The latest proposed text example specifies "content-decryption" now but symmetric keys exchanged this way can also be for encryption too. Also, the symmetric key encrypted by the public key was in fact an encryption key when the originator used it.

Proposed rewording preserving both bits:
"
The keyEncipherment bit is asserted when the subject public key is used for transport of a secret key or data encryption using an intermediate secret key. For example, when a public key is to be used to encrypt a secret cipher key that will encrypt some data or key, then this bit shall asserted.

The dataEncipherment bit is asserted when the subject public key is used for directly enciphering user data other than cryptographic keys.
"

Proposed rewording with only one bit:
"
The dataEncipherment bit is deprecated. If asserted then this bit now has the same meaning as keyEncipherment. The keyEncipherment bit is renamed to "encipherment" and is asserted when either of the previous bits were asserted. Whenever a public key is used to encrypt data or keys then this bit shall be asserted.
"

Regards,

Simon McMahon.



Simon McMahon

Work: (07) 31311420
Mobile: (043) 2294180


>>> Sharon Boeyen <sharon.boeyen@xxxxxxxxxxx> 05/13/05 05:44am >>>
I like the proposed text also. My only suggestion is could we add
"symmetric" in the sentence for dataEncipherment, so it would read "...
without the use of an intermediate symmetric key." I don't feel strongly
about this but do think it helps with the clarity.

Cheers,
Sharon

-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On
Behalf Of Russ Housley
Sent: Thursday, May 12, 2005 11:22 AM
To: Denis Pinkas
Cc: ietf-pkix@xxxxxxxx 
Subject: Re: key usage - key encipherment or data encipherment



Denis:

Thanks.  I think you suggestion improves the text.

Russ

At 10:44 AM 5/12/2005, Denis Pinkas wrote:
>Russ,
>
>>Since we are working on an update to RFC 3280, I propose the following
>>revisions to these descritions.
>
>>      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 for key management by encrypting a symmetric content-encryption
>>      key, then this bit shall asserted.
>>      The dataEncipherment bit is asserted when the subject public key
>>      is used for directly enciphering raw user data without the use of
>>      an intermediate symmetric cipher.
>
>Thank you for this strawman proposal. I would rather propose:
>
>       The keyEncipherment bit is asserted when the subject public key is
>       used for enciphering private or secret keys, i.e. for key transport.
>       For example, this bit shall be set when a public RSA key is to be
>       used for encrypting a symmetric content-decryption key or an
>       asymmetric private key.
>
>       The dataEncipherment bit is asserted when the subject public key
>       is used for directly enciphering raw user data without the use of
>       an intermediate key.
>
>Reasons:
>
>a) "Key transport" is not explicit enough. The purpose is to encipher
>either a private key or a secret key.
>
>b) The example is not clear enough: "RSA key" can be a private key or a
>public key, hence why "public" has been added.
>
>c) The key that is communicated is a decryption key rather than an
>encryption key, hence why "content-encryption" has been changed into 
>"content-decryption".
>
>d) The example has been extended to cover the case of an asymmetric 
>cipher
>as well.
>
>e) In the last statement, the intermediate key would not necessarily be 
>a
>symmetric cipher, hence why "symmetric" has been deleted. Also "cipher" 
>has been replaced by "key'.
>
>Note that the current text from X.509 is:
>
>   c) keyEncipherment: for enciphering keys or other security information,
>      e.g. for key transport;
>
>   d) dataEncipherment: for enciphering user data, but not keys or other
>      security information as in c) above;
>
>Denis


***********************************************************************************
This email, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s).  This confidentiality is not waived or lost, if you receive it and you are not the intended recipient(s), or if it is transmitted/received in error.

Any unauthorised use, alteration, disclosure, distribution or review of this email is prohibited.  It may be subject to a statutory duty of confidentiality if it relates to health service matters.

If you are not the intended recipient(s), or if you have received this email in error, you are asked to immediately notify the sender by telephone or by return email.  You should also delete this email and destroy any hard copies produced.
***********************************************************************************