Re: [lamps] Call for adoption of draft-perret-prat-lamps-cms-pq-kem-01

[Michael Richardson <[e-mail]>]

Russ Housley <[e-mail]> wrote:
    > There has been some discussion of
    > https://datatracker.ietf.org/doc/draft-perret-prat-lamps-cms-pq-kem/.
    > During the discussion at the virtual interim earlier this month, we
    > agree to have a call for adoption of this document.

I have read the document, and I support adoption.

I have some editorial comments which I'll send to the authors directly.
One bigger thought that I wanted to share is:

  doc> As the National Institute of Standards and Technology (NIST) is still
  doc> in the process of selecting the new post-quantum cryptographic
  doc> algorithms that are secure against both quantum and classical
  doc> computers, the purpose of this document is to propose a generic
  doc> "algorithm-agnostic" solution to protect in confidentiality the CMS
  doc> envelopped-data content against the quantum threat : the KEM-TRANS
  doc> mechanism. This mechanism could thus be used with any key
  doc> encapsulation mechanism, including post-quantum KEMs or hybrid KEMs.

This is in the introductory text, and I think that we should probably justify
why we are doing this work *now* as opposed to waiting.  While it is possible
that our document will take so long that reviewers won't have to ask, I hope
not, and so I think that outside of this community we may cause many questions.

    > Should the LAMPS WG adopt “Use of Post-Quantum KEM in the Cryptographic
    > Message Syntax (CMS)l” in draft-perret-prat-lamps-cms-pq-kem-01?

    > Please reply to this message by Monday, 10 October 2022 to voice your
    > support or opposition to adoption.

I found section 3 very clear and very well written.

I/we/ANIMA-WG are a user of CMS in RFC8366 and RFC8995, and there are
scenarios where we sould have to create very long lived (multi-decade
possibly) voucher artifacts.
I think, but I'm unclear, if this document applies to signatures as well as
algorithms.   In general, we sign with a keyed hash and that's the "CEK"
equivalent.  We need this for 8366, but also in general for current users of RFC4108.

I imagine that whatever we do (cryptographically) for CMS, we will also do
for COSE and JOSE.


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-