Dale, Thank you for the review. Comments are inline...
On 2025-05-19 9:38 p.m., Dale Worley via Datatracker wrote: Document: draft-ietf-lamps-x509-slhdsa Title: Internet X.509 Public Key Infrastructure: Algorithm Identifiers for SLH-DSA 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://wiki.ietf.org/en/group/gen/GenArtFAQ><https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-lamps-x509-slhdsa-07 Reviewer: Dale R. Worley Review Date: IETF LC End Date: 2025-05-22 IESG Telechat date: unknown I have only reviewed the document for readability by a non-expert. I expect the security people to check the algorithms and their uses, and also the ASN.1 constructions. Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Technical issues: The authors should verify that it is intended that the ASN.1 module does not define signature algorithm numbers 20 through 31. Nits/editorial comments: 1. Introduction When a pure or pre-hash mode needs to be differentiated, the terms Pure SLH-DSA and HashSLH-DSA are used. It reads oddly that "Pure SLH-DSA" has a space in it but "HashSLH-DSA" does not. Is there a reason for this difference? FIPS 205 refers to the general algorithm as SLH-DSA. There are pure and pre-hash variants of the algorithm. FIPS 205 uses HashSLH-DSA to identify the pre-hash version, and also refers to HashSLH-DSA as "the pre-hash SLH-DSA (signature,version)." But for the pure version they just refer to it as "the pure SLH-DSA (signature,version)." Since there is no NIST name for the pure version, we used the term "Pure SLH-DSA" but wanted to use the NIST term "HashSLH-DSA" for the pre-hash version. Separate algorithm identifiers have been assigned for SLH-DSA at each of these security levels, fast vs small, and SHA2 vs SHAKE256. Better to make it clear that not just each attribute alone has an OID but each *combination* has an OID, and that pure vs. pre-hash is also part of the combination: Separate algorithm identifiers have been assigned for SLH-DSA for each combination of these security levels, fast vs small, SHA2 vs SHAKE256 and pure mode vs pre-hash mode. will update. 3. Algorithm Identifiers The AlgorithmIdentifier type, is defined as follows: AlgorithmIdentifier{ALGORITHM-TYPE, ALGORITHM-TYPE:AlgorithmSet} ::= SEQUENCE { I would have found reading this to be smoother if it had stated before the definition that this is not a new definition: The AlgorithmIdentifier type is defined in [RFC5912] as follows: AlgorithmIdentifier{ALGORITHM-TYPE, ALGORITHM-TYPE:AlgorithmSet} ::= SEQUENCE { will update -- The same OID is used to identify an SLH-DSA public key and its associated signature algorithm. Is this the proper/usual use of "identify"? Clearly, the OID identifies the algorithm, as there is only one algorithm with a given OID. But there are many keys that use the same algorithm; the OID for the algorithm is an attribute of the key but is not sufficient to identify it. RFC 8410 uses "The same algorithm identifiers are used for identifying a public key, a private key, and a signature." Would that be better? 11. References For the ASN.1 Module in the Appendix of this document, I would be specific: For the ASN.1 Module in Appendix A of this document, will update Appendix A. ASN.1 Module I note that while section 3 defines signature algorithm numbers 20 through 31 and 35 through 46, the ASN.1 module only defines numbers 35 through 46. Though I assume that the authors have a reason that the pure algorithms have no defined identifier in the module, it would be good to explain why for the naive reader. I propose to change The Pure SLH-DSA OIDs are: to The Pure SLH-DSA OIDs are defined in [I-D.ietf-lamps-cms-sphincs-plus]'s ASN.1 module and reproduced here for convenience: Thanks, Daniel Van Geest [END]
_______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
