Dale: Thanks for the review. > Reviewer: Dale Worley > 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://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-lamps-cms-sha3-hash-03 > Reviewer: Dale R. Worley > Review Date: 2024-04-27 > IETF LC End Date: 2024-05-03 > IESG Telechat date: [not known] > > Summary: > > This draft is basically ready for publication, but has a nit that > should be fixed before publication. > > I assume that the ASN.1 module has been reviewed by someone with the > necessary expertise. (I do not have that expertise.) Yes, the ASN.1 module compiles. > Nits/editorial comments: > > 5.2. KMAC128-KDF and KMAC256-KDF > > The following is probably clearer if one is familiar with these > algorithms. The text states > > The parameters are: I see. These are talking about two different things. For this part, I suggest: The parameters to the KMAC128 and KMAC256 functions are: Then, I suggest the addition of the following paragraph after the description of the four parameters to prepare the reader for what is coming: The K parameter is known to all authorized parties; it is often the output of a KEM Decap() operation. The X parameter is assembled from data that is transmitted by the originator. The L parameter is determined by the size of the output keying material. The S parameter is optional, and if it is provided by the originator, it is passed in the parameters field of the KDF algorithm identifier. > and follows with a list of four parameter values. But later it says > > When the id-kmac128 or id-kmac256 is used as part of an algorithm > identifier, the parameters field MUST be absent if no customization > label is used for S. If any other value is used for S, then > parameters field MUST be present and contain the value of S, encoded > as Customization. Here is it talking about the ASN.1 AlgorithmIdentifier, which is composed of an object identifier and optional parameters. I think this text is correct. > Some differentiation should be made between the two senses of > "parameters". In particular, it would help to state here where the K, > X, and L "parameters" are put, since they aren't put in the > "parameters field". I think the above changes address this comment. > Also, the phrase "if no customization label is used for S" is not > quite correct, as it implies that something else could be "used for > S". I think the correct wording is "if there is no customization > label S", which reflects that S has been stated to be "optional". I suggest: When the id-kmac128 or id-kmac256 is used as part of an algorithm identifier, the parameters field MUST be absent when there is no customization label S. If any value is provided for S, then the parameters field MUST be present and contain the value of S, encoded as Customization. Russ -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
