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

[Russ Housley <[e-mail]>]

David:

Based on guidance from the CA/Browser forum, most certificates include a key usage extension.

When it is missing, I guess one needs to figure out whether it is a key agreement key or a key transport key based on the algorithm identifier.

There is some advice about keyUsage extensions for particular algorithms is available in RFC3279, RFC4055, and RFC4491.  I probably missed some...

Russ


> On Dec 22, 2022, at 2:55 PM, von Oheimb, David <[e-mail]> 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?
> 
> (
> 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
>