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-21Reviewer: Elwyn DaviesReview Date:
2026-09-07IETF LC End Date: 2026-08-18IESG Telechat date: 2026-09-17Summary: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 GalaxySent from my Galaxy
_______________________________________________
Gen-art mailing list -- [email protected]
To unsubscribe send an email to [email protected]
