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

[Russ Housley <[e-mail]>]

The proposed changes seem fine to me.

Russ

> On Jan 10, 2023, at 11:56 AM, Brockhaus, Hendrik <[e-mail]> wrote:
> 
> Russ
> 
> Thank you for this clarification on how to choose the right key
> management technique.
> As explained by David, we currently focus on the key usage in the
> certificate used for protecting the certificate request message. As key
> usage may be set wrongly in this certificate, this is not the best way to
> specify which key management technique to use.
> As explained in this mail thread we should point at the type of the public
> key instead of the key usage extension.
> Therefore, I propose the following clarification in the central key
> generation section in draft-ietf-lamps-cmp-updates Section 2.7.
> 
> OLD
>   The choice of the key management technique to be used by the sender
>   depends on the credential available at the recipient:
>   *  Recipient's certificate that contains a key usage extension
>      asserting keyAgreement: The content-encryption key will be
>      protected using the key agreement key management technique, as
>      specified in CMS section 6.2.2 [RFC5652].  This is the preferred
>      technique.
>   *  Recipient's certificate that contains a key usage extension
>      asserting keyEncipherment: The content-encryption key will be
>      protected using the key transport key management technique, as
>      specified in CMS section 6.2.1 [RFC5652].
> 
> NEW
>   The choice of the key management technique to be used by the sender
>   depends on the credential available at the recipient:
>   *  Recipient's certificate with a public key that supports key agreement
>       and where any given key usage extension allows keyAgreement: The
>       content-encryption key will be protected using the key agreement
>       key management technique, as specified in CMS Section 6.2.2
>       [RFC5652].
>   *  Recipient's certificate with a public key that supports key transport
>       and where any given key usage extension allows keyEncipherment:
>       The content-encryption key will be protected using the key
>       transport key management technique, as specified in CMS Section
>       6.2.1 [RFC5652].
> 
> @Roman, I hope this clarification is OK to be implemented in AUTH48.
> If not, please let me know.
> 
> Implementing this change in draft-ietf-lamps-cmp-updates, we also
> propose like to adapt draft-ietf-lamps-lightweight-cmp-profile Section
> 4.1.6 accordingly.
> 
> Hendrik
> 
>> Von: Russ Housley <[e-mail]> 
>> 
>> David:
>> 
>> 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.
>> 
>> The CMS-related algorithm specifications make it pretty clear.  For
>> example, RFC 5753 tells ho to use ECC Algorithms in CMS.  I do not see
>> how an implementer would try to use KeyTransRecipientInfo after
>> reading that document.
>> 
>> Maybe some pointers are needed in CMP in the central key generation
>> section.
>> 
>> Russ
>