Hi Elwyn, thanks for the review. Your first nit will be addressed in the next document revision.
Regarding the KEM function naming conventions, I've already responded to your review of the pq-composite-kem document, but that is being held for moderation for some reason, and is relevant to this draft as well so I'll repeat it here. Summarizing for this draft, this is a profile of RFC 9629 for Composite ML-KEM, so we think it makes most sense to use the RFC 9629 terminology, with mapping to the pq-composite-kem terminology where necessary. And for this mapping it is pretty necessary because the Encapsulate()/Encaps() parameters are actually returned in a different order. This mapping text will be added to the next document revision. The full state of the KEM naming conventions: The IETF already has 4 conventions for KEM function names, see (probably incomplete) table below, so unless you think we can herd all the draft-ietf- cats below, this complaint may be a lost cause. Adding to the fun, Encap(), kemEncaps() and Encaps() return (ss, ct), while Encapsulate() returns (ct, ss). At least the current set of drafts are mostly consistent. HPKE drafts follow RFC 9180 convention, CMS drafts follow RFC 9629 convention, most of the remainder follow RFC 9954/FIPS 203 convention. If anything, text should be added to drafts when it makes sense to map from one convention to another (e.g. I will do this for draft-ietf -lamps-cms-composite-kem to make CMS convention to draft-ietf-lamps-pq-composite-kem convention. Others may need to map HPKE convention to FIPS 203 convention when bringing ML-KEM into HPKE). IETF Origin RFC Topic Key Generation Encapsulation Decapsulation IETF Documents Using This Convention RFC 9180 HPKE GenerateKeyPair() Encap()/AuthEncap() Decap()/AuthDecap() RFC 9458 (OHTTP) draft-ietf-cose-hpke draft-ietf -cose-hpke-pq-pqt draft-ietf -jose-hpke-encrypt draft-ietf -jose-hpke-pq-pqt draft-ietf -hpke-pq RFC 9629 CMS KeyGen() Encapsulate() Decapsulate() RFC 9690 (CMS) RFC 9810 (CMP [uses CMS]) RFC 9936 (CMS) draft-ietf -lamps-cms-composite-kem draft-ietf -lake-authkem-edhoc RFC 9958 PQ/T Hybrid Terminology kemKeyGen() kemEncaps() kemDecaps() draft-ietf -emu-pqc-eapaka draft-ietf -jose-pqc-kem RFC 9954 (also FIPS 203) TLS 1.3 Hybrid KeyGen() Encaps() Decaps() RFC 9980 (OpenPGP) draft-ietf-tls-mlkem draft-ietf -ipsecme-ikev2-mlkem draft-ietf -ipsecme-hybrid-kem-ikev2-frodo draft-ietf-lake-pqsuites draft-ietf-lamps-pq-composite-kem draft-ietf-openpgp-nist-bp-comp draft-irtf-cfrg-hybrid-kems draft-irtf-cfrg-concrete-hybrid-kems Thanks, Daniel ________________________________ From: Elwyn Davies via Datatracker <[email protected]> Sent: Thursday, September 10, 2026 10:53 PM To: [email protected] <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: draft-ietf-lamps-cms-composite-kem-01 ietf last call Genart review Document: draft-ietf-lamps-cms-composite-kem Title: Composite ML-KEM for use in Cryptographic Message Syntax (CMS) Reviewer: Elwyn Davies Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-lamps-cms-composite-kem-01 Reviewer: Elwyn Davies Review Date: 2026-09-10 IETF LC End Date: 2026-08-18 IESG Telechat date: 2026-09-17 Summary: Ready with a couple of nits. Apologies for the very late delivery of this review. This was mainly caused by my somehow getting diverted onto reviewing draft-ietf-lanmps-pq-composite-kem-21 to which this draft is intimately related. This turned out to be much more challenging and I only realized my error when I tried to submit my review and in the process seriously upset Cloudfare. We now have three options for the Encap(s(ulate)) and Decap(s(ulate)) between the two Composite MLKEM drafts and RFC 9180. Time for some agreement! Major issues: None Minor issues: None Nits/editorial comments: Abstract and s1: Need to expand ML-KEM in 'combinations of MLKEM' in the abstract and in 'which combine ML-KEM' in s1. s1.3, Definition of Encapsulate(ek): The function name used in draft-ietf-lamps-pq-compsite-kem-21 is Encaps (there has been discussion as to whether Encap as used in RFC 9180 woulld be more appropriate). s1.3, Definition of Decapsulate(dk, c): The function name used in draft-ietf-lamps-pq-compsite-kem-21 is Decaps (there has been discussion as to whether Decap as used in RFC 9180 woulld be more appropriate).
_______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
