Internet X.509 Public Key Infrastructure: Algorithm Identifiers for SLH-DSA
draft-ietf-lamps-x509-slhdsa-09

Thanks for the work done in this document.

Two minor changes in the abstract as this I-D has an intended status of "standard track".

s/This document *describes* the conventions.../This document *specifies* the conventions.../

s/... private keys are also *described*./... private keys are also *specified*./

Hi Kaveh, Scott, Stefan-Lukas, Daniel, and Stavros, 

Thanks for the effort put into this specification. Special thanks for supplying an Ops Considerations Section.

Thanks to Linda Dunbar for the OPSSIR review and Russ of the clarification. 

# Generic comments

## A lot of duplicated text

I think that the specification can be simplified by removing a lot of duplicate text and simply reference appropriate docs, mainly draft-ietf-lamps-cms-sphincs-plus. This impacts Sections 3/5 in particular.

## Notation conventions

Please update your terminology section to explain the notation conventions for at least the following:

* || 

* id-slh-dsa-* 

* id-hash-slh-dsa-*

# Introduction

## Small and Fast

CURRENT:
   SLH-DSA offers three security levels.  The parameters for each of the
   security levels were chosen to be at least as secure as a generic
   block cipher of 128, 192, or 256 bits.  There are small (s) and fast
   (f) versions of the algorithm, and the option to use the SHA2
   algorithm family [FIPS180] or SHAKE256 [FIPS202] as internal

Can we add some words about this characterization? Specifically, what does meant “small” and “fast” in this context?

## Assignments

CURRENT:
   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.

Please indicate these are assigned by whom.

# Section 3

CURRENT:
   The contents of the parameters component for each algorithm MUST be
   absent.

Do we need to include this given that the text was copied from draft-ietf-lamps-cms-sphincs-plus and that spec already says:

Section 3 of draft-ietf-lamps-cms-sphincs-plus:
   The parameters field of the AlgorithmIdentifier for the
   SLH-DSA public key MUST be absent.

The same comment applies for a similar text in Section 4.

# Section 6

## At least one parameter

CURRENT:
   The intended application for the key is indicated in the keyUsage
   certificate extension; see Section 4.2.1.3 of [RFC5280].  If the
   keyUsage extension is present in a certificate that indicates an id-
   slh-dsa-* (Pure SLH-DSA) or id-hash-slh-dsa-* (HashSLH-DSA)
   identifier in the SubjectPublicKeyInfo, then at least one of the
   following MUST be present:

       digitalSignature; or
       nonRepudiation; or
       keyCertSign; or
       cRLSign.


As we say “at least one the parameter, I guess, we need to change this part to be:

NEW:
   The intended application for the key is indicated in the keyUsage
   certificate extension; see Section 4.2.1.3 of [RFC5280].  If the
   keyUsage extension is present in a certificate that indicates an id-
   slh-dsa-* (Pure SLH-DSA) or id-hash-slh-dsa-* (HashSLH-DSA)
   identifier in the SubjectPublicKeyInfo, then at least one of the
   following MUST be present:

       digitalSignature
       nonRepudiation 
       keyCertSign
       cRLSign

Or similar. Otherwise, I don’t partse “at least” and “or” use here.

## No sure to parse the use of “or” 

Maybe consider:

OLD:
   If the keyUsage extension is present in a certificate that indicates
   an id-slh-dsa-* (Pure SLH-DSA) or id-hash-slh-dsa-* (HashSLH-DSA)
   identifier in the SubjectPublicKeyInfo, then the following MUST NOT
   be present:

       keyEncipherment; or
       dataEncipherment; or
       keyAgreement; or
       encipherOnly; or
       decipherOnly.

NEW:
CURRENT:
   If the keyUsage extension is present in a certificate that indicates
   an id-slh-dsa-* (Pure SLH-DSA) or id-hash-slh-dsa-* (HashSLH-DSA)
   identifier in the SubjectPublicKeyInfo, then the following MUST NOT
   be present:

       keyEncipherment,
       dataEncipherment,
       keyAgreement,
       encipherOnly, and
       decipherOnly.

# Section 8

## As some OIDs are assigned by US NIST, are there implications on the maintenance of the usage described in this spec?

## Section 9 has the following:

CURRENT:
   An SLH-DSA tree MUST NOT be used for more than 2^64 signing
   operations.

How is this tracked/ensured? Can this be covered in the Ops Cons section?

# Section 9: Mysterious SHOULD

CURRENT:
   Implementers SHOULD consider their particular use cases and may
   choose ….

   Likewise, implementers SHOULD consider their particular use cases and
   ….

I don’t understand what this concretely means or implies.

# IANA

CURRENT:
   For the ASN.1 Module in Appendix A of this document, IANA is
   requested to assign an object identifier (OID) for the module
   identifier (TBD1) with a Description of "id-mod-x509-slh-dsa-2024".
   The OID for the module should be allocated in the "SMI Security for
   PKIX Module Identifier" registry (1.3.6.1.5.5.7.0).

I’m not familiar with the naming convention, but any reason why the final name module isn’t id-mod-x509-slh-dsa-2025?

# Appendix A: Note can be removed:

CURRENT:
      |  RFC EDITOR: Please replace TBD2 with the value assigned by IANA
      |  during the publication of [I-D.ietf-lamps-cms-sphincs-plus].
      |  Also please replace [I-D.ietf-lamps-cms-sphincs-plus]
      |  throughout this document with a reference to the published RFC.

 …

       FROM SLH-DSA-Module-2024  -- in [I-D.ietf-lamps-cms-sphincs-plus]
       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
         id-smime(16) id-mod(0) id-mod-slh-dsa-2024(TBD2) } ;

I think this can be updated to reflect the final assignment made for this.

Please update to use 81 per https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml and remove the RFC Editor note.

Cheers,
Med

Thank you to Dale Worley for the GENART review.

** Section 5.  Given that there is normative guidance on how AlgorithmIdentifier should be used in this section, RFC5912 should be cited normatively.