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

From: "Simon McMahon" <[email-masked]>
Date: Thu, 12 May 2005 12:14:40 +1000

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: [email-masked] (Peter Gutmann)
Date: Sun, 15 May 2005 20:05:20 +1200

"Simon McMahon" <[email-masked]> writes:

>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 I originally saw your posting I thought that what they were doing was a
typical clueless-user action, but on thinking about it a bit more it's
actually quite logical.  Unless you're intimately familiar with the crypto
involved, it's quite sensible to use dataEncryption to mean, well, data
encryption (in the way you describe above).

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

Yup.  It's like the old digitalSignature vs. nonRepudiation bits, no-one could
actually clearly define what nonRepudiation did, which is why it was changed
to the current contentCommitment.  So now we have:

  digitalSignature = ephemeral signatures (e.g. for authentication to an
                     online server).

  nonRepudiation = long-term signature (e.g. for document signatures).

The logical corollary from this is to set:

  keyEncipherment = ephemeral session key establishment (e.g. SSL).

  dataEncipherment = content-encryption key establishment (e.g. S/MIME).

Since everyone that's using dataEncipherment is using it for that anyway, it
clarifies the situation and requires no change in existing apps.

(As for real raw data-encipherment, if anyone is actually using that, give
 them a new flag contentEncapsulation or something with a name that can't be
 confused with anything else).

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

Yup, that's a perfect summary of the current situation.  I don't know if I'm
too happy with combining the bits, the crypto-purist in me wants to keep a
distinction between SSL vs. S/MIME-type keys for access control purposes, but
the practical part of me says this will never work, because there's no way for
a user (even if they do know the difference in key types, which very few do)
to be able to manage this in any way via a crypto API.

The standard crypto API has some form of "gimme a key" function that returns a
key for a particular user.  Some of the more sophisticated ones extend this to
"gimme a key usable for encryption" (although the best known, CryptoAPI,
allows you to use an encryption-only key for signatures because so many users
can't understand anything other than a one-size-fits-all key).  None that I'm
aware of (and I've used quite a few) allow you to specify the usage of a key
for short-term but not long-term signatures, or session vs. data-encryption
key management.  The only thing they understand is "sign" and "encrypt".  So
even if you clarify keyEncipherment and dataEncipherment, there's no way to
manage the usage in any known CryptoAPI.

The best the crypto software vendor can do at that point is to leave it to the
end user to check that when they call "encrypt" to encrypt an ephemeral key,
the associated cert isn't set up to only encrypt a content-encryption key.
I'll leave readers to decide what the chances are of that ever working.

Peter.

---

From: Russ Housley <[email-masked]>
Date: Sun, 15 May 2005 15:16:12 -0400

Peter:

This would be quite a change from the current meaning of the bits, not a 
clarification.  I do not support such a change.

Russ

---

From: [email-masked] (Peter Gutmann)
Date: Mon, 16 May 2005 18:55:16 +1200

Russ Housley <[email-masked]> writes:

>clarification.

Well, it would change the current text describing the bits, but not the way
the bits are being used in practice.  In other words the changed text would
then match the way the bits are actually being used.  It'd resolve the
ambiguity and fix the current problem in a single step.

Peter.