[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: key usage - key encipherment or data encipherment


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


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 <housley@xxxxxxxxxxxx> 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. ***********************************************************************************