Subject: Re: key usage - key encipherment or data encipherment

From: "Kazin, Joel" <[email-masked]>
Date: Wed, 11 May 2005 05:49:43 -0500

Peters rewording makes it clearer.

At 12:34 AM 5/11/2005 -0500, [email-masked] wrote:

Andrew Sciberras <[email-masked]> writes: 

>     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, then this bit shall asserted. 
> 
>      The dataEncipherment bit is asserted when the subject public key 
>      is used for enciphering user data, other than cryptographic keys. 

Quoting that won't help (I've seen this sort of thing before) because as far

as the user is concerned what's being encrypted is data, so the valid bit to

use is dataEncipherment (quite logical to them).  What might help is to make

this more explicit in the text: 

  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.  This bit MUST NOT be set when the intention is to 
  encipher intermediate cryptographic keys rather than raw user data. 

Peter. 

Joel S. Kazin CPA, CISA, CISSP, CISM
Senior Consultant
Atos Origin
40 Old Sleepy Hollow Road
Pleasantville, New York 10570-3802
USA
Phone  +1 914-769-8780
Mobile  +1 914-564-1484
email    [email-masked]
www.atosorigin.com <http://www.atosorigin.com/>

---

From: Sharon Boeyen <[email-masked]>
Date: Thu, 12 May 2005 15:44:53 -0400

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Russ Housley
Sent: Thursday, May 12, 2005 11:22 AM
To: Denis Pinkas
Cc: [email-masked]
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.
>
>>      used for key management by encrypting a symmetric content-encryption
>>      key, then this bit shall asserted.
>>      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:
>
>       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.
>
>       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

---

From: "Simon McMahon" <[email-masked]>
Date: Fri, 13 May 2005 11:19:20 +1000

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 <[email-masked]> 05/13/05 05:44am >>>

Cheers,
Sharon

-----Original Message-----

Denis:

Russ

>      security information as in c) above;

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

---

From: <[email-masked]>
Date: Fri, 13 May 2005 09:09:50 GMT

IMO password or PIN is also considered as a secret key,
then which applications or protocols are demanding the dataEncipherment 
bit?

Thanks

Diego

----- Mensaje Original -----
Remitente: Russ Housley [email-masked]
Destinatario: [email-masked]
Fecha: Jueves, Mayo 12, 2005 9:21pm
Asunto: Re: key usage - key encipherment or data encipherment

>     used for enciphering private or secret keys, i.e., for key 
>transport.      For example, this bit shall be set when a RSA public 
>key is to be
>    an intermediate symmetric cipher. Note that the use of this
>    bit is extremely uncommon; almost all applications use
>    key transport or key agreement to establish a symmetric key.
>

---

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 13 May 2005 11:52:02 +0100

How about calling the bits "The encryption bit" and "The other
encryption bit" :-)  

Jokes aside, can anyone recall the justification for having 2 different
bits for key and data encryption?

Is there any realistic security threat involved with allowing both
purposes for the same bit?

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Simon McMahon
> Sent: den 13 maj 2005 03:19
> To: [email-masked]; [email-masked];
[email-masked]
> Cc: [email-masked]
> Subject: RE: key usage - key encipherment or data encipherment
> 
> 
> 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.
> 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.
> 
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.
> for directly enciphering user data other than cryptographic keys.
> "
> 
> 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.
> From: [email-masked]
[mailto:[email-masked]]
> On
************************************************************************
**
> *********
> 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.
>
************************************************************************
**
> *********

---

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 13 May 2005 16:43:27 +0100

Steve,

Even though I'm not really convinced about the benefits, maybe I should
clarify that I don't want to change the bits either for legacy reasons
and in order to stay in sync with X.509.

I'm fine with the earlier provided wordings.

Stefan Santesson

> From: Stephen Kent [mailto:[email-masked]]
> Sent: den 13 maj 2005 15:33
> To: Stefan Santesson
> Cc: Simon McMahon; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> At 11:52 AM +0100 5/13/05, Stefan Santesson wrote:
> Despite the observation that many folks setting these bits, or
> applications using these bits, don't really know the difference,
> there is a difference. From a security perspective, it can be
> important to know whether the bits being decrypted are data to be
> handed to a user or app, or keys to be kept within the key management
> subsystem. Hence there is a legitimate, security benefit that could
> be obtained IF people set the bits properly.
> 
> I am hesitant to have us remove this potentially useful distinction
> merely because folks have not been smart enough to make good use of
> it so far.
> 
> Steve

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 13 May 2005 13:38:08 -0400

To add to what Steve Kent has said in this e-mail, there is a separate bit
for D-H type protocols.  It is called keyAgreement.

I also agree with Steve's other posting of maintaining the distinction
between key encihperment and data encipherment.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Kent
Sent: Friday, May 13, 2005 10:15 AM
To: Wen-Cheng Wang
Cc: [email-masked]
Subject: Re: key usage - key encipherment or data encipherment

At 5:48 PM +0800 5/13/05, Wen-Cheng Wang wrote:
>I also hesitate to accept the term "key transport", which will result
>in over-narrowing down the usage scope of the keyEncipherment bit. As 
>Arshad pointed out, sometimes the intention is not to transport the 
>encrypted symmetric key to anywhere. Besides, it is often that the 
>handshake protocol is not simply a "key transport" process; it is more 
>often be a more complex "key exchange" process. For example,
>the SSL handshake protocol names it as "key exchange"
>instead of "key transport". Would it be valid for a SSL server
>cert to be asserted with that keyEncipherment bit?
>To avoid the possible dispute on the definition of
>similar terms, I would like to suggest to drop the term "key
>transport" from the definition of the key usage bit. (However,
>I think it is OK to use "key transport" as an example to
>explain the the definition of the key usage bit.

As commonly employed, a client uses an RSA public key associated with 
a server to encrypt and transport key bits that will later be used to 
create encryption and integrity keys for protecting the session. That 
is an example of key transport. If one used the Diffie-Hellman key 
agreement option for SSL, that would be accurately be described as a 
key exchange, but that is rarely the case, in practice.  So I am 
puzzled by the characterization above.

Steve

---

From: "Simon McMahon" <[email-masked]>
Date: Mon, 16 May 2005 10:25:01 +1000

Wen-Cheng Wang's last post looks OK to me but I would drop "RSA" and "content-decryption" from the example. I still don't see how an RSA public key can directly encrypt a private key, unless its heaps smaller, so I dropped that from the example too. 'Private' keys are also 'secret' keys anyway. I didn't change 'dataEncipherment' from Wang's post.

proposed text:
      The keyEncipherment bit is asserted when the subject public key is
      used for enciphering cryptographic keys or keying materials.
      For example, this bit shall be set when a RSA public key is to be
      used for key transport that involves encrypting a secret key.
 
     The dataEncipherment bit is asserted when the subject public key
     is used for directly enciphering raw user data, other than cryptographic
     keys or keying materials, without the use of an intermediate symmetric
     cipher. Note that the use of this bit is extremely uncommon; almost all
     applications use key transport or key agreement to establish shared
     cryptographic keys.

The 'note' at the end of dataEncipherment effectively deprecates this bit but I'm sure it will continue to see many more interoperability issues in the future.

I think that Peter's observation:
  keyEncipherment = ephemeral session key establishment (e.g. SSL).
  dataEncipherment = content-encryption key establishment (e.g. S/MIME).
Is what industry will continue to do regardless of the RFC text since a bit that is there with no obvious use may as well get used for something.

The 'PIN' reference from another post was another good grey area that can justify the use of either bit however the RFC gets worded.

The overloading of the bits to imply security policy for the private key's decryption op is the riskiest use of these bits but will obviously continue too.

The bits, as defined by the RFC, obviously don't matter very much to PKI security which is why no-one could nail down what they actually mean and industry usage varies so widely. They are just an interoperability issue waiting to happen (again).

Simon McMahon.

Simon McMahon

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

---

From: Russ Housley <[email-masked]>
Date: Thu, 12 May 2005 15:21:02 -0400

There has been a whole lot of discussion about these paragraphs.  Since 
some of the discussion has not been CCed to the PKIX mail list, I am 
posting the resulting words.

      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 RSA public key is to be
      used for encrypting a symmetric content-decryption key or an
      asymmetric private key.

I hope we a re close to closure on this one....

Russ

---

From: "Simon McMahon" <[email-masked]>
Date: Tue, 17 May 2005 09:03:05 +1000

The example for 'keyEncipherment' should not include an "RSA public key encrypting an asymmetric private key", which, if it is also RSA is too big to encrypt with the public key. Surely, an RFC shouldn't list impossible cases as examples.

Simon.

Simon McMahon

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

>>> Russ Housley <[email-masked]> 05/13/05 05:21am >>>

Russ

---

From: <[email-masked]>
Date: Tue, 17 May 2005 07:42:24 GMT

----- Mensaje Original -----
Remitente: "Simon McMahon" [email-masked]
Destinatario: [email-masked], [email-masked]
Fecha: Martes, Mayo 17, 2005  1:03am
Asunto: Re: key usage - key encipherment or data encipherment

>
>The example for 'keyEncipherment' should not include an "RSA public 
>key encrypting an asymmetric private key", which, if it is also RSA 
>is too big to encrypt with the public key. Surely, an RFC shouldn't 
>list impossible cases as examples.
>

---

From: <[email-masked]>
Date: Tue, 17 May 2005 14:15:59 GMT

But, if the asymmetric private key is based on elliptic curves?

Diego

---

From: "Simon McMahon" <[email-masked]>
Date: Fri, 20 May 2005 11:13:24 +1000

Eric,

> The user doesn't really care or even want to know whether an intermediate symmetric key in involved or not.

I agree. The increased complexity of the rewording for 'keyEncipherment' is even more information that the user, or implementer, doesn't need to know.

Having two bits for encryption just makes room for interoperability problems like those already mentioned. Where exactly is the benefit? Earlier remarks that it should be preserved until people are "smart enough" to make good use of it dont help much.

If the use of 'dataEncipherment' is deprecated, but not reused for another purpose, we would have only 1 bit 'keyEncipherment' that could be renamed 'encipherment'. The proposed rewording discourages use of 'dataEncipherment' anyway. This would have little impact on implementations that use 'keyEncipherment' already, or implementations that set both bits because the distinction is so unclear and irrelevant.

Simon.

Simon McMahon

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

>>> Eric Norman <[email-masked]> 05/20/05 07:16am >>>

On May 19, 2005, at 1:33 PM, Hallam-Baker, Phillip wrote:

> I have been following the thread, I think the cures proposed may be
> worse than the problem.
>
> I think that the sentences can be adequately clarified by stating that
> dataEncipherment is to be set if the key is to be used to directly
> encipher data, i.e. without the use of an intermediate session key.

I might as well chime in with my take, which is different yet.  And 
since
those two bits have already appeared in standards documents, probably
not worth anything.

I think that from a user's point of view, all the user cares about is 
that
the data is protected in transit and perhaps at rest.  The user doesn't
really care or even want to know whether an intermediate symmetric key
in involved or not.  From that point of view, the distinction seems 
rather silly.

Now, if someone came up with a key escrow scheme that would escrow
the symmetric key, then that might be interesting.  But that's yet 
another
thread.

Eric Norman
University of WIsconsin