Reviewer: Brian Weis Review result: Has Nits 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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
