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

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

Russ

Thank you for your quick feedback.
I will queue this change for draft-ietf-lamps-cmp-updates AUTH48 and
implement the related alignment in draft-ietf-lamps-lightweight-cmp-profile
with the next update.

BTW, there are two changes in the queue for draft-ietf-lamps-cmp-updates
AUTH48. Is there a way to already submit them to reflect them in the latest
version on datatracker?

Hendrik

> Von: 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
> >