Subject: key usage - key encipherment or data encipherment

From: "Simon McMahon" <[email-masked]>
Date: Wed, 11 May 2005 10:33:58 +1000

Hi,
 
I have had a recent interoperability issue with a application vendor that didn't like the key-usage attributes in a cert from a CA vendor's certificate. Signing certs work fine, it was an encryption cert that failed.
 
CA sets key-usage = "key encipherment".
Application wants to encrypt some XML data so looks for key-usage = "data encipherment". Reason - because XML is data, not a key.

I believe the application vendor is wrong and I explained that the RSA key actually encrypts an AES key so it doesn't directly encrypt the data but they want an official "pkix" ruling based on the standard so can someone please refer me to a statement in the standard that clears this up.
 
Thanks,
 
Simon McMahon.

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

Simon McMahon

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

***********************************************************************************
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: Andrew Sciberras <[email-masked]>
Date: Wed, 11 May 2005 11:53:28 +1000

Hi,

 From RFC2459:

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

Andrew Sciberras
eB2Bcom Australia.

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 11 May 2005 17:34:28 +1200

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

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 11 May 2005 17:41:46 +1200

[email-masked] writes:

>This is a recurring problem with applications.  

If this is a recurring problem then it's a strong indicator that the wording
of the spec needs to be changed to address it.

>If your vendor is cooperative, that will make your choice easier.

They almost never are.  The standard flow for this sort of thing is:

  1. Vendor does something silly.

  2. Vendor uses ambiguous wording of spec to justify their silliness
     because they don't want to fix their code.

  3. User has the option of breaking their code to match the vendor 
     silliness, or going somewhere else (learning to flip burgers, for
     example).

Peter (who just last week went through an argument with a vendor who claimed
       that some open-ended wording in the X.509v3 spec (before sundry
       corrections and bugfixes are applied, and not counting X.509v4 updates
       or any bugfixes to that) allowed them to do something silly, and they 
       weren't going to change their code, and anyone who didn't like it could
       bugger off).

---

From: "Wen-Cheng Wang" <[email-masked]>
Date: Wed, 11 May 2005 15:47:29 +0800

>  encipher intermediate cryptographic keys rather than raw user data.
It is better to clarify that it is legitimate to assert both the keyEncipherment bit
and the dataEncipherment bit in one certificate. In that case, it means that the
key (e.g., RSA key) may be used for enciphering intermediate cryptographic
keys or directly enciphering raw user data (e.g., user password).

Wen-Cheng Wang

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 11 May 2005 21:39:04 +1200

"Wen-Cheng Wang" <[email-masked]> writes:

>It is better to clarify that it is legitimate to assert both the
>keyEncipherment bit and the dataEncipherment bit in one certificate. In that
>case, it means that the key (e.g., RSA key) may be used for enciphering
>intermediate cryptographic keys or directly enciphering raw user data (e.g.,
>user password).

Saying you can use both bits won't help, it still leaves it ambiguous to users
as to what dataEncipherment should be used for.  One interpretation I've heard
of is keyEncipherment = exchange of session keys (SSL), dataEncipherment =
data encryption (S/MIME).

Peter.

---

From: Andrew Sciberras <[email-masked]>
Date: Wed, 11 May 2005 19:32:14 +1000

Peter Gutmann wrote:

Yeah, I see your point Peter.

Simon seems to know what he's talking about and made the point that the
key is actually encrypting an AES key, he then wanted a standards based
opinion.

I think RFC 2459 clearly states what each of the key usage bits are to
be used for.

I don't think that the user's interpretation of what's being encrypted
is significant at all. Its more about the developers who are writing
decision making code understanding the various usages. At that point
the developer should be very aware of how the key associated with the
certificate is being used and therefore 2459's description should
suffice.

Peter.

Andrew Sciberras.

---

From: [email-masked]
Date: Tue, 10 May 2005 23:05:46 -0400

Simon,

Your interpretation matches the PKIX interpretation.  Since the RSA key is 
used to encrypt the AES key, it is key encipherment not data encipherment.  
The AES key enciphers the data.

This is a recurring problem with applications.  In general, policies used by 
most PKIs (including the U.S. government) forbid setting the data encipherment 
bit.  There are a number of security problems taht can arise if an application 
actuially uses the RSA key to encipher the datat directly.  It is almost 
always a better choice to encrypt data under a good symmetric algorithm and 
encipher the key using the RSA algorithm.  Unfortunatley, a number of 
applications have been implemnnted using your vendor's interpretations.

This presents you with an uncomfortable choice - set data encipherment to 
enable your apps, but open a security vulnerability, or make the security 
purist choice and break your app.  If your vendor is cooperative, that will 
make your choice easier.

Tim Polk

Quoting Simon McMahon <[email-masked]>:

> 
> Hi,
>  
> I have had a recent interoperability issue with a application vendor that
> didn't like the key-usage attributes in a cert from a CA vendor's
> certificate. Signing certs work fine, it was an encryption cert that failed.
>  
> Application wants to encrypt some XML data so looks for key-usage = "data
> encipherment". Reason - because XML is data, not a key.
> 
> I believe the application vendor is wrong and I explained that the RSA key
> actually encrypts an AES key so it doesn't directly encrypt the data but they
> want an official "pkix" ruling based on the standard so can someone please
> refer me to a statement in the standard that clears this up.
>  
> Thanks,
>  
> Simon McMahon.
>  
>  
> 
> Simon McMahon
>  
> Work: (07) 31311420
> Mobile: (043) 2294180
> 
> 
> 
> Simon McMahon
> 
> Work: (07) 31311420
> Mobile: (043) 2294180
> 
> 
> 
> 
> 
*******************************************************************************
****
> 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: Russ Housley <[email-masked]>
Date: Wed, 11 May 2005 11:06:39 -0400

Simon:

If they are encrypting the XML data directly with the RSA key (which is 
very unlikely), then they are correct.

The traditional way to handle this is to generate a random 
content-encryption key (CEK) and then encrypt the XML data with a symmetric 
algorithm using the CEK.  The CEK is encrypted with the RSA key from the 
certificate.  Thus, the RSA key is really being used to encrypt only 
symmetric keys.

Russ

  At 08:33 PM 5/10/2005, Simon McMahon wrote:

>actually encrypts an AES key so it doesn't directly encrypt the data but 
>they want an official "pkix" ruling based on the standard so can someone 
>please refer me to a statement in the standard that clears this up.
>
>Thanks,
>
>Simon McMahon.
>
>
>
>Simon McMahon
>
>Work: (07) 31311420
>Mobile: (043) 2294180
>
>
>
>Simon McMahon
>
>Work: (07) 31311420
>Mobile: (043) 2294180
>
>
>
>
>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 
>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: Russ Housley <[email-masked]>
Date: Wed, 11 May 2005 11:40:16 -0400

I believe that RFC 3280 is quite clear that more than one of these bits can 
be set.  It says:

    This profile does not restrict the combinations of bits that may be
    set in an instantiation of the keyUsage extension.  However,
    appropriate values for keyUsage extensions for particular algorithms
    are specified in [PKIXALGS].

Russ

At 03:47 AM 5/11/2005, Wen-Cheng Wang wrote:

>keyEncipherment bit

---

From: "Miguel A Rodriguez" <[email-masked]>
Date: Wed, 11 May 2005 12:20:46 -0500

Does anyone use dataEncipherment?

Miguel A Rodríguez
SeguriData
Mexico

At 03:47 AM 5/11/2005, Wen-Cheng Wang wrote:

>>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:
>and the dataEncipherment bit in one certificate. In that case, it means

>that the

---

From: Russ Housley <[email-masked]>
Date: Wed, 11 May 2005 15:57:12 -0400

As far as I know, SET was the only protocol that used data 
encipherment.  Of course, SET used the same RSA public key for both data 
encipherment and key encipherment.

Russ

---

From: "Wen-Cheng Wang" <[email-masked]>
Date: Thu, 12 May 2005 12:56:42 +0800

FYI:  In the Asia PKI Interoperability Guideline (prepared by
Asia PKI Forum), we suggest CA vendors or operators to
assert both the keyEncipherment and dataEncipherment bits
in an encryption cert. The main reason is that we intend to allow
users to use the public key for directly enciphering raw user data.
We certainly know that the public key is usually used to encrypt
intermediate cryptographic keys. However, what if someday
users really want to use that public key for directly enciphering
raw user data (e.g., user password)? For the sake of supporting
both kinds of encipherment, it is better to assert both bits in the
beginning. I see no reason why a public key certified by an
"encryption" certificate should be prohibit from being used for
directly enciphering small-size user data. The second reason is
that we believe that asserting both bits is helpful to achieve
maximum Interoperability. By asserting both bits, no matter which
interpretation the application implementators adopt, the cert
should always work.
Anyway, I believe that it is not harmful if the dataEncipherment
bit is asserted in an encryption cert in addition to the
keyEncipherment bit.

Wen-Cheng Wang

----- Original Message ----- 
From: "Russ Housley" <[email-masked]>
To: "Miguel A Rodriguez" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, May 12, 2005 3:57 AM
Subject: RE: key usage - key encipherment or data encipherment

>
> As far as I know, SET was the only protocol that used data encipherment.  Of course, SET used the 
> same RSA public key for both data encipherment and key encipherment.
>
> Russ
>

---

From: "Wen-Cheng Wang" <[email-masked]>
Date: Thu, 12 May 2005 13:10:18 +0800

Russ,

Yes, RFC 3280 is quite clear for that. However, I worried
that the discussions of this thread might mislead the
participants into believing that the two bits are mutually
exclusive. Therefore, I simply want to remind the
participants of this thread the fact that the keyEncipherment
bit and dataEncipherment bit can work well togethor.

Wen-Cheng Wang

---

From: "Wen-Cheng Wang" <[email-masked]>
Date: Thu, 12 May 2005 13:33:10 +0800

Peter,

I think your clarification about the distinction between the
keyEncipherment bit and the dataEncipherment bit is good.
It would be better if RFC 3280 and X.509 could revise
the explanation of the dataEncipherment bit based on your
clarification.
However, I worried that the statement "This (dataEncipherment)
bit MUST NOT be set when the intention is to encipher
intermediate cryptographic keys rather than raw user data" might
mislead the reader to believe that the keyEncipherment bit and the
dataEncipherment bit are mutually exclusive. Therefore, I suggest
to revise the statement as "The dataEncipherment bit should not be
use to represent the intention of allowing enciphering intermediate
cryptographic keys. In that case, the keyEncipherment bit should
be set."

Wen-Cheng Wang

----- Original Message ----- 
From: "Peter Gutmann" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, May 11, 2005 5:39 PM
Subject: Re: key usage - key encipherment or data encipherment

---

From: [email-masked] (Peter Gutmann)
Date: Sun, 15 May 2005 17:39:03 +1200

>Does anyone use dataEncipherment?

That depends on which question you're asking.  Lots of people use
dataEncipherment, but I've never found anyone who uses dataEncipherment the
way it's meant to be used (whenever I see it used I try and find out from the
original user what they're doing with it.  It's never for the X.509 definition
of dataEncipherment).  So the answer is both yes and no.

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Sun, 15 May 2005 20:06:30 +1200

"Wen-Cheng Wang" <[email-masked]> writes:

>However, I worried that the statement "This (dataEncipherment) bit MUST NOT
>be set when the intention is to encipher intermediate cryptographic keys
>rather than raw user data" might mislead the reader to believe that the
>keyEncipherment bit and the dataEncipherment bit are mutually exclusive.
>Therefore, I suggest to revise the statement as "The dataEncipherment bit
>should not be use to represent the intention of allowing enciphering
>intermediate cryptographic keys. In that case, the keyEncipherment bit should
>be set."

Thanks, that change helps clarify the text.

Peter.