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

From: Russ Housley <[email-masked]>
Date: Thu, 12 May 2005 10:05:10 -0400

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.

Russ

At 10:14 PM 5/11/2005, Simon McMahon wrote:
>Russ,
>
>They were calling an 'encrypt' function to encrypt XML data and they gave 
>it an RSA key (the cert actually) to do it. Of course it internally made 
>an AES key but they never saw it until the interoperability issue made 
>them look. From what they saw at the level they were looking the 
>interpretation was reasonable. When the transport key is well hidden and 
>simply part of the protocol then it looks just like RSA is encrypting big 
>slabs of data. If you know that RSA is bound by the modulus size then you 
>know what is really happening but not all users of PKI know RSA so well. 
>Why should they?
>
>Couple this interpretation of key-usage with a dubious decision to reject 
>encryption requests with certs that dont have key-usage='data 
>encipherment' and you have an interoperability problem. I say "dubious" 
>because it is a public key so you cannot enforce usage policy anyway. The 
>CA could set both flags to fix it, which by the way was the vendors 
>preferred solution, but its not my CA or their CA and the CA doesn't do 
>that. Why should they?
>
>This reference, in my opinion, allows the ambiguous interpretation:
> >     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.
>
>In this case the public key is clearly "intended" to be used to encrypt 
>the XML data but it just doesn't do it directly because it cant. The term 
>"key management" also has associations with more basic and explicit key 
>management operations like installing trusted root certs or secure 
>installation of shared secret keys etc. In this case it is much less 
>obvious that key management is happening because the key is bundled with 
>the data. It looks just like the public key is encrypting the data.
>
>In my opinion there are 3 cases presented as 2 in the RFC.
>1. RSA encrypts data - hardly ever used.
>2. RSA implicitly encrypts keys so it can really encrypt bulk data - 
>common usage.
>3. RSA explicitly encrypts keys for explicit key management functions - 
>common usage.
>The current bits separate 1 from 2/3 yet people make the interpretation 
>that they split the more common 2 from 3 assuming 1 and 2 are the same 
>thing. Knowledge of RSA is required to know that 1 and 2 are different.
>
>Peter's comment "This bit MUST NOT be set when the intention is to 
>encipher intermediate cryptographic keys rather than raw user data" is 
>most relevant in my case. Does PKIX support this clarification?
>
>In my opinion this problem will not entirely go away by clarifying the 
>standard because most people dont read it before they implement something. 
>The two bits are there and as long as they are both there then the mistake 
>will be made by busy developers. Unenforceable key-usage policy, to 
>"public" keys, will also continue to be implemented. People will come 
>looking for clarification once they have an interoperability issue but by 
>then it is often too late - the issue usually gets decided by who has the 
>biggest corporate balls. In this case it wasn't too late so thanks for the 
>assistance.
>
>If I could recommend a change to the standard then I would suggest 
>dropping one of the encryption bits and just have a single key-usage = 
>"encryption". Give it the value the same as "key-encryption" since this is 
>the common usage.
>
>Thanks,
>
>Simon McMahon.
>
>
>Simon McMahon
>
>Work: (07) 31311420
>Mobile: (043) 2294180
>
>
> >>> Russ Housley <[email-masked]> 05/12/05 01:06am >>>
>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:
>
> >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.
> >************************************************************************* 
> **********
>
>
>
>***********************************************************************************
>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: Denis Pinkas <[email-masked]>
Date: Thu, 12 May 2005 16:44:28 +0200

Russ,

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

       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

>> They were calling an 'encrypt' function to encrypt XML data and they 
>> gave it an RSA key (the cert actually) to do it. Of course it 
>> internally made an AES key but they never saw it until the 
>> interoperability issue made them look. From what they saw at the level 
>> they were looking the interpretation was reasonable. When the 
>> transport key is well hidden and simply part of the protocol then it 
>> looks just like RSA is encrypting big slabs of data. If you know that 
>> RSA is bound by the modulus size then you know what is really 
>> happening but not all users of PKI know RSA so well. Why should they?
>>
>> Couple this interpretation of key-usage with a dubious decision to 
>> reject encryption requests with certs that dont have key-usage='data 
>> encipherment' and you have an interoperability problem. I say 
>> "dubious" because it is a public key so you cannot enforce usage 
>> policy anyway. The CA could set both flags to fix it, which by the way 
>> was the vendors preferred solution, but its not my CA or their CA and 
>> the CA doesn't do that. Why should they?
>>
>> In this case the public key is clearly "intended" to be used to 
>> encrypt the XML data but it just doesn't do it directly because it 
>> cant. The term "key management" also has associations with more basic 
>> and explicit key management operations like installing trusted root 
>> certs or secure installation of shared secret keys etc. In this case 
>> it is much less obvious that key management is happening because the 
>> key is bundled with the data. It looks just like the public key is 
>> encrypting the data.
>>
>> 3. RSA explicitly encrypts keys for explicit key management functions 
>> - common usage.
>> The current bits separate 1 from 2/3 yet people make the 
>> interpretation that they split the more common 2 from 3 assuming 1 and 
>> 2 are the same thing. Knowledge of RSA is required to know that 1 and 
>> 2 are different.
>>
>> standard because most people dont read it before they implement 
>> something. The two bits are there and as long as they are both there 
>> then the mistake will be made by busy developers. Unenforceable 
>> key-usage policy, to "public" keys, will also continue to be 
>> implemented. People will come looking for clarification once they have 
>> an interoperability issue but by then it is often too late - the issue 
>> usually gets decided by who has the biggest corporate balls. In this 
>> case it wasn't too late so thanks for the assistance.
>>
>> "encryption". Give it the value the same as "key-encryption" since 
>> this is the common usage.
>>
>> Thanks,
>>
>> Simon McMahon.
>>
>>
>> Simon McMahon
>>
>> Work: (07) 31311420
>> Mobile: (043) 2294180
>>
>>
>> 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
>>
>> >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

---

From: Sam Roberts <[email-masked]>
Date: Thu, 12 May 2005 11:17:55 -0400

>       used for encrypting a symmetric content-decryption key or an

Hi Denis,

I think this text has the same problem as the current. In other words,
somebody might read it and think "I'm not encrypting a key, I'm
encrypting email, and I'm "transporting" a word document, not a key, so
this isn't the bit I should look for". This is what happens now.

I can't think of appropriate wording, but if the goal is to make it
clear to non-security experts so the bit is used consistently, a little
bit more explanation is needed.

>       is used for directly enciphering raw user data without the use of

This is clear, I think.

Cheers,
Sam

> Reasons:
> 
> a) "Key transport" is not explicit enough. The purpose is to encipher 
> either a private key or a secret key.
> 

-- 
http://www.certicom.com

---

From: Russ Housley <[email-masked]>
Date: Thu, 12 May 2005 11:22:04 -0400

Denis:

Thanks.  I think you suggestion improves the text.

Russ

At 10:44 AM 5/12/2005, Denis Pinkas wrote:
>symmetric cipher, hence why "symmetric" has been deleted. Also "cipher" 
>has been replaced by "key'.
>

---

From: Dino Esposito <[email-masked]>
Date: Thu, 12 May 2005 18:25:38 +0200

IMO, the typical reader of a RFC is a technician. Especially for a RFC 
full of PKI jargon.
If we wanted to write for a layman reader, we should write an encyclopedia
I think the Pinkas' proposal is quite clear.

Dino Esposito

Sam Roberts wrote:

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

---

From: Sam Roberts <[email-masked]>
Date: Thu, 12 May 2005 13:46:41 -0400

> IMO, the typical reader of a RFC is a technician. Especially for a RFC 

Many of the PKI flags are sufficiently succinctly subscribed that they
have been interpreted differently by "technicians". Didn't an earlier
poster recount an experience with a *certificate authority* that had
been using the wrong flag?  If an issuer of certs doesn't get it, then
its not clear enough, IMHO. Making it clear enough that this
conversation doesn't have to happen again would be useful. It helps none
of us if people who (arguably) don't know enough about pki/crypto deploy
systems wrongly, because we get asked to interop with them.

My 2 cents.

> If we wanted to write for a layman reader, we should write an encyclopedia

Its always a balance, but when interop has failed to occur, perhaps we
need to be more encyclopedic.

> I think the Pinkas' proposal is quite clear.

You probably understood the original text, too.

Cheers,
Sam

> >>d) The example has been extended to cover the case of an asymmetric 
> >>cipher as well.
> >>

-- 
http://www.certicom.com

---

From: "todd glassey" <[email-masked]>
Date: Thu, 12 May 2005 11:04:39 -0700

Hmmm - The person you are writing for is an IT Auditor because there is NO
PKI system that is ever going to be deployed commercially from say 9/11
onward and especially after SOX that is going not have an Auditor's
Approval. That means something I tried to get this WG to think about several
years ago and that was Practice or Use Models for the IP's themselves.

Todd Glassey, CISM, CIFI

----- Original Message ----- 
From: "Dino Esposito" <[email-masked]>
To: "Sam Roberts" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, May 12, 2005 9:25 AM
Subject: Re: key usage - key encipherment or data encipherment

> >>d) The example has been extended to cover the case of an asymmetric
cipher
> >>symmetric cipher, hence why "symmetric" has been deleted. Also "cipher"
has
> >>>>standard that clears this up.
and
> >>>>>Any unauthorised use, alteration, disclosure, distribution or review
of