IETF Last Call Review of draft-ietf-lamps-x509-slhdsa-07
review-ietf-lamps-x509-slhdsa-07-genart-lc-worley-2025-05-19-00

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-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?

   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.

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 {

--

   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.

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, 

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.

[END]