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