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

["Brockhaus, Hendrik" <[e-mail]>]

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