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

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

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?

(
Side note:
The only explicit hint in this direction may be the key usage extension that can optionally be contained in the recipient cert - as written in RFC 5652:


6.2.1<https://www.rfc-editor.org/rfc/rfc5652#section-6.2.1>.  KeyTransRecipientInfo Type


      The recipient's certificate must contain a key transport public
      key.  Therefore, a recipient X.509 version 3 certificate that
      contains a key usage extension MUST assert the keyEncipherment

      bit.


and in


6.2.2<https://www.rfc-editor.org/rfc/rfc5652#section-6.2.2>.  KeyAgreeRecipientInfo Type


      The recipient's certificate must

      contain a key agreement public key.  Therefore, a recipient X.509
      version 3 certificate that contains a key usage extension MUST
      assert the keyAgreement bit.


Yet this does not help if the cert does not contain a key usage extension, or if the key usage extension is present and its bits allow for more than one choice.
Moreover, the key usage extension may even exclude, by intention or by mistake, the use of all algorithmically suitable techniques.
)

AFAIK, so far there are no key types/algorithms that support more than one key management technique (such as, both key transport and key agreement).
Thus the concern may be just hypothetical because at least for the well-known key types (RSA, EC, and DH) it should be clear which technique to use.
Still we'd be interested in learning about explicit specification/guidance, maybe in some accompanying RFC, that we could provide to implementers.

David and Hendrik