Re: [lamps] CMS: selection of key management technique to use for EnvelopedData

["von Oheimb, David" <[e-mail]>]

Thanks Russ for your further immediate response.

On Fri, 2022-12-23 at 11:59 -0500, Russ Housley wrote:

Since neither the original CMS RFC 5652 nor its update mention the topic how to select the key management technique to use,
the questions remains: was this on purpose?

  *   If not, I'd say this an omission to be sorted out.
  *   If yes, I'd expect some reasoning why, and a concrete pointer to, e.g., some other RFC (maybe, on specific uses like S/MIME) where concrete guidance is given.

I am sure you know this, but they can be mixed in the general case.  For example, one recipient could have a certificate with an RSA public key, and another recipient could have a certificate with an ECDH public key.  The sender would use KeyTransRecipientInfo for the first one, and the sender would use KeyAgreeRecipientInfo for the other one.  For this reason, I am not sure what guidance would be added to CMS.

Indeed there may be multiple recipients with certificates of different key types,
but still the expected guidance should better say for each of those types which key management technique to use.
So

  *   if all recipients have an RSA cert, it is sufficient to use KeyTransRecipientInfo,
  *   if all recipients have an (EC)DH or GOST R 34.10-94 cert, it is sufficient to use KeyAgreeRecipientInfo,
  *   if the recipients have both flavors, both key transport and key agreement needs to be used.


As mentioned in my first email (quoted again below), in the central key generation use case for CMP v3 (and maybe any further cert enrollment protocols),
CMS is used to convey the new private key. There it is just one recipient, and the sender needs to decide which key management technique to use.


RFC 2630 was published in June 1999.  This was the first version of CMS that included more that one flavor of RecipientInfo.  In the 20+ years since RFC 2630 was published, this is the first time that this has been a concern.

I wonder why nobody brought this up before -
maybe simply because cryptographically educated users of CMS know (and others should learn by failure) that RSA does not support key agreement and ECC does not support key transport.

If an implementation supports a particular public key type (identified by the subjectPublicKeyInfo.algorithm in the certificate), then the implementation should "know" whether it is a key transport or a key agreement algorithm.

The point is that the implementation of a CMS sender (which is a central key generation authority in our new use case)
usually supports both KeyTransRecipientInfo (typically for RSA) and KeyAgreeRecipientInfo (typically for DCDH).
So it must implement some logic which one (or both in some cases) to choose in which situation, based on the set of recipient certs at hand.
And even if it supports just one of the two key management techniques, it needs to know for which (unsupported) key types to throw an error.
This logic apparently has been implicit for meanwhile 23+ years.

If the algorithm identifier is unknown or unsupported, then the implementation will throw an error.

This is fine, of course, in particular since in general the implementer of the sender cannot know in advance which types of recipient keys the sender may be confronted with.
Essentially the same holds of course for the expected guidance: it can only be given for key types known so far.

David


On Wed, 2022-12-21 at 18:15 +0100, David von Oheimb wrote:
Russ et al.,

when doing extended tests on central (i.e., server-side) key generation with CMP Updates, where CMS is used for sending the newly generated private key encrypted to the client,
we stumbled over potential differences between the key management techniques allowed by the client certificate and those techniques actually supported by the key type in that cert.

Sorting this out, we tried to find in RFC 5652<https://www.rfc-editor.org/rfc/rfc5652.html>, in particular section 6 on EnvelopedData, some guidance how to select the key management technique to use for a given recipient cert.
Yet it looks like this is kind of implicit. For instance, if the public key in the recipient cert is of type RSA, only key transport makes sense, while for EC keys only key agreement makes sense.
Is there any specification that makes the (intended) selection of the key management technique explicit, or has this been deliberately left open?
[...]