IETF Last Call Review of draft-ietf-ipsecme-ikev2-pqc-auth-09
review-ietf-ipsecme-ikev2-pqc-auth-09-secdir-lc-housley-2026-07-17-00

I reviewed this document as part of the Security Directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the Security Area
Directors.  Document authors, document editors, and WG chairs should
treat these comments just like any other IETF Last Call comments.

Document: draft-ietf-ipsecme-ikev2-pqc-auth-09
Reviewer: Russ Housley
Review Date: 2026-07-18
IETF LC End Date: 2026-07-31
IESG Telechat date: unknown

Summary: Has Nits


Major Concerns: None


Minor Concerns:

Section 6 says:

   The different parameter sets of SLH-DSA are identified via
   AlgorithmIdentifier ASN.1 objects, as specified in NIST [CSOR] and
   referenced in PKIX Algorithm Identifiers for the SLH-DSA [RFC9909].
   [FIPS205] defines two signature modes: pure mode and pre-hash mode.
   PKIX Algorithm Identifiers for the SLH-DSA [RFC9909] specifies the
   use of both Pure SLH-DSA and HashSLH-DSA in Public Key Infrastructure
   X.509 (PKIX) certificates and Certificate Revocation Lists (CRLs).
   
I think that discussing the fact that OIDs have been assigned for 
HashSLH-DSA leads to confusion since Section 3.2 says:

   This document specifies the use of
   pure mode for signature-based authentication in IKEv2, where the
   message is signed directly along with domain separation information.
   The data used for authentication in IKEv2, as described in
   Section 2.15 of IKEv2 [RFC7296], ...
   
   Please remove discussion of the HashSLH-DSA OIDs.


Nits:

Section 3.2: s/ML-DSA and SLH-DSA algorithms/ML-DSA and SLH-DSA algorithms, respectively/

Section 3.2: s/that implements side-/that implement side-/


Note:

I checked the hex strings for the OIDs in Appendix B, and they are correct.