Re: key usage - key encipherment or data encipherment

[pgut001@xxxxxxxxxxxxxxxxx (Peter Gutmann)]

"Simon McMahon" <Simon_McMahon@xxxxxxxxxxxxxxxxx> 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).

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

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.