> s2, para 4 - definitions of Encaps and Decaps: I concur with a previous > reviewer who opined that as an IETF document it would be appropriate to stick > with Encap and Decap.
I can’t find the previous review, so I’ll respond here. 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 Regards, Daniel From: elwynd <[email protected]> Sent: Thursday, September 10, 2026 11:12 PM To: [email protected]; [email protected]; [email protected]; [email protected] Subject: [lamps] Extra Gen-art review of draft-ietf-lamps-pq-composite-kem-21 Due to a misunderstanding/cock-up I spent a considerable amout of time creating this review as opposed to its compnion and much simpler document draft-ietf-lamps-cms-composite-kem01. I thought it was worth submitting it. Cheers, Elwyn Davies For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-lamps-cms-composite-kem-21 Reviewer: Elwyn Davies Review Date: 2026-09-07 IETF LC End Date: 2026-08-18 IESG Telechat date: 2026-09-17 Summary: On the right track. Firstly, apologies for the very late review. The material is rather out of my comfort zone and necessitated a deal of background reading to produce a decent review, not speeded up by holidays and a week of traditional windmill maintenance. The decision to follow in the footsteps of RFC 9180 by using an enhanced Python syntax to document the functional primitives is as far as I know pretty novel and has vcaused a few hiccups IMO. The later sections beyond s4 are in good shape as far as I can see but I am far from an expert. Major issues: s1.2 et seq: The use of an 'enhanced' Python syntax style for describing the functionality of the operations in the document as introduced in s1.2 is, as far as I am aware, unique to this document. This document builds on RFC 9180 which appears to be the first document to employ Python or Python derived syntax for reperesenting code fragments but seems to use standardPytho syntax.. Whilst the syntax used is fairly 'obvious' to anyone with basic programming skills, I guess there should be a reference that enables a reader to check on the meaning of pieces of meta-Python should they be unfamiliar with the language - I note that this was not done in RFC 9180. In turn, this imposes a need for reviewers such as me to verify that pieces of meta-Python are actually valid Python statements subject to the syntax extensions set out in s1.2. There are a number of function definitions in the text that do not actually use the Python syntax (primarily missing the initia declaratory 'def' atom.) Given the emphasis on using Python structure at the outset, it would seem to me that the function definitions in s3 should be more formally in Python syntx. Of particular concern is the overloading of the use of round brackets to encapsulate value pairs as a single item. For example, we need to be clear whether the Decap function takes takes as argument a value pair or are its arguments a pair of simple items syntacticaly enclosed in round brackets - and can I write a syntax analyser which won't get confused. There is also confusion over what the syntactic status of a value pair is. For example in s3.2 at step 3 of the Encap process, the NOT function is applied to what looks like a value pair and apparently delivers a boolean result implying that the value pair is effectively a boolean value. Hmm. The text indicates that this could be implied if the values are invalid but this is not made explicit as far as I can see. Minor issues: Use of 'algorithm'; The term 'algorithm' is stated in the s1.1 Conventions to be 'generally' associated with a function which has a registered OID. In practice (cf RFC 9180 which has some attachment to this document) an OID references a collection of functionality referred to collectively as an algorithm which perform component aspects of a, possibly distributed (in time and/or space) task. The algorithm may be parameterized (as with encryption key size) and may be implemented by a number of independently invocable functions referred to as 'primitives' in RFC 9180. This document suggests in s1.1 that it intends to adhere to the OID/algorithm connection - indeed the majority of the document does adhere to this proposal - but the usage in s1.2 and s2 is in practice referring to 'primitives' or functional components that implement parts of the algorithm with which they are associated and would not have separate OIDs. Nits/editorial comments: Abstract and s1: It would be good to reference RFC 9794 both in the Abstract and right at the start of s1. RFC 9794 provides a deeper backgtround to the problem and provides the terminology and basic structure of the solution offered in this draft. s1, para 6: s/that meets the needs/that meet the needs/ s1.1, para 3: It would be helpful to provide a refereence to the IANA OID registry. s1.1: Is there any good reason why the labels for the items ALGORITHM, APPLICATION BACKWARDS COMPATIBILITY, COMBINER, COMPOSITE CRYPTOGRAPHIC ELEMENT, POST-QUANTUM TRADITIONAL (PQ/T) HYBRID SCHEME, PROTOCOL BACKWARDS COMPATIBILITY, and SHARED SECRET KEY are capitaized - their originals in RFC 9180 are are typically in title case. The use of hanging label indented pargraphs might be appropriate. s1.1: The term COMPOSITE CRYPTOGRAPHIC ELEMENT dos not appear to be used in the document. Which part(s) of constructions defined here should be referred to by this term? s1.1: The term 'composite ciphertext' is used on a number of occasions - a definition might be useful. s1.2, concatenation of byte arrays: Given the association with RFC 9180, it might be more consistent to use the concat() notation defined in Section 3 of RFC 9180. s1.2, definition of (a, _): As far as I can tell, this form is not used in the document. s1.2, definition of Func<TYPE>(): This form is (as far as I can tell) only used in reminding the implementers of the KeyGen, Encap(s), and Decap(s) primitive functions that the input parameter values for the primitives are determined by the OID with which the primitive will be associated. I suggest that the terms night be called Composite-ML-KEM-<OID-name> which groups the primitives associated with that OID. s2, para 4 - definitions of Encaps and Decaps: I concur with a previous reviewer who opined that as an IETF document it would be appropriate to stick with Encap and Decap. s2.1 and s2.2: The presentation of the Encap(s) and Decap(s) fuctions should be as properly formatted Python function definitions. s2.1 and s2.2: Should the return statements of the Encap(s) functions read 'return( shared_secret, enc)' in line with the input usage for the Decaps primitives? s2.1, last two paragraphs: I suggest that these paragraphs be presented as separate subsidiary sections s2.1.1 and s2.1.2 with the title of s2.1.1 being 'Note on the choice....' and s2.1.2 being Status of Algorithm RSAOAEPKEM. s2.2, last para: as with last para of s2.1. ss3.2, 3.3 and 3.4: In line with the Python structure decision, the functions in these sections should be formulated as proper Python function definitions. s.3.1.1: Trailing full stop (or period) is missing. (oo, er!) s3.2, para1: s/to behave exactly the same as/to behave in exactly the same manner as/ s3.2, item 3: As discussed above, the paired values tested with 'NOT' need to be carrying around a BOOLEAN value representing whether the Encap(s) processes that generated them completed successfully s3.4, SHA3-256 encoding call: Replace prameter list with correspponding 'concat() functio n call. s4: The coding is not in Python format. In particular ss4.1 and 4.3 should use 'match' i n place of 'switch'. s9.2.1: This glossary would be more user friendly if the definitions were in separate paragraphs or bullet points. Sent from my Galaxy Sent from my Galaxy
_______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
