I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.

The summary of the review is Has Nits.

This document defines the usage of Key Encapsulation Mechanism (KEM)
algorithms for CMS. In particular a content encryption key (CEK)
used to protect CMS content is protected by a key encryption key
(KEK), which is itself derived from a shared secret (ss). The shared
secret is generated using KEM public key cryptography algorithms.

Some clarification would improve the document.

1. There are three symmetric keys defined here, which are not always
referred to by the same words. It would help the reader if they
were used consistently. I think the easiest way to resolve this is
to include the acronym after first use (e.g., "content-encryption-key
(CEK)" and then use the acronym each time afterwords.  Here are
some cases where an inconsistent key name is used.  
-- "originator-generated content-encryption key" -> "CEK" 
-- "pairwise shared secret" in Section 2 is apparently "ss" in 
   Section 1.

2. Section 1.3 essentially states that CMS version numbers are
unreliable, and as long as the CMS can be evaluated the version
number is irrelevant. I assume this is a generic CMS issue unrelated
to this document and is current practice. If so, that might be worth
mentioning.

3. Section 2 states "The originator randomly generates the
content-encryption key, and then all recipients obtain that key."
This is the first reference to the content-encryption key, and it
isn't clear yet how it's distributed (e.g., is it out of band,
within CMS, etc.). It would be nice to be more clear in that sentence,
for example by appending it with something like "... as an encrypted
object within the KEM CMS object."

4. Section 2 list item 2 for the originator and recipient both
mention "data that is sent in the clear". Is this the "ukm" in the
KEMRecipientInfo structure? If so, instead of "sent in the clear"
text such as "included in the CMS structure". Otherwise, one wonders
whether the cleartext is integrity protected and could be changed
by a man-in-the-middle.

5. Section 3, "rid" definition. The text is long, and it  would be
helpful if it also include an object definition defined showing the
two alternative (such as is done in Section 4).

6. Section 5 says "An acceptable KDF MUST accept an IKM, L, and
info as inputs." The order of providing them to the KDF is critical
for interoperability.  Is there intended to be a defined order in
this document, or is the KDF definition expected to define the
order?

7. Security Considerations states many SHOULDs involving security
levels being "at least the security level" of another part of KEM.
It  would have have been more conventional to specify MUSTs in order
to achieve a consistent security level. I assume there is some
rationale for specifying SHOULDs (e.g., operational considerations
of algorithm deployment), which should be stated.

8. As quantum-secure KEM algorithms using the
KeyGen()/Encapsulate()/Decapsulate() model are less well-known that
typical public-key encryption algorithms it would be helpful to
provide a reference to at least one algorithm.