UNCLASSIFIED / NON CLASSIFIÉ Hi Tiru, I reviewed the update and validated the DER encodings. It looks good to me. Thanks!
Jonathan -----Original Message----- From: tirumal reddy <[email protected]> Sent: October 20, 2025 4:10 AM To: Hammell, Jonathan F - [he/il] <[email protected]> Cc: Tero Kivinen <[email protected]>; [email protected]; [email protected]; [email protected] Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-pqc-auth-04 (Ends 2025-10-22) EXTERNAL EMAIL - USE CAUTION / COURRIEL EXTERNE - FAITES PREUVE DE PRUDENCE Thanks Jonathan for the review, addressed the comments in https://github.com/tireddy2/ikev2-pqc-auth/pull/34. -Tiru On Sat, 18 Oct 2025 at 01:43, Hammell, Jonathan F - [he/il] <[email protected] <mailto:[email protected]> > wrote: UNCLASSIFIED / NON CLASSIFIÉ I have reviewed and support this document proceeding to publication. I have a suggestions below to address a few minor issues. The introduction sentence of 3.2.1, "For integrating PQC... the approach used in [RFC8420] is followed" can be omitted. The approach is coherently outlined in the following paragraphs, and this brief sentence is potentially confusing until explained further in the fourth paragraph. In Section 4, it would be helpful to include the DER encoding of an AlgorithmIdentifier object for each of the three security levels to be used in the multi-octet format of SUPPORTED_AUTH_METHODS (RFC 9593). Similarly for the combinations in Section 5. In Section 5, it should be made clear that the selection of the hash function for the parameters is not via SIGNATURE_HASH_ALGORITHMS. This could be fixed with "For hash function selection, the algorithm uses SHA-256 ([FIPS180]) for security level 1 and both SHA-256 and SHA-512 ([FIPS180]) for security levels 3 and 5. Alternatively, SHAKE256 ([FIPS202]) can be used across all security levels. Those hash function selections are internal to SLH-DSA implementations, and are not to be confused with those in the SIGNATURE_HASH_ALGORITHMS notification payload." Best regards, Jonathan -- Canadian Centre for Cyber Security (http://cyber.gc.ca/en <http://cyber.gc.ca/en> ), Communications Security Establishment, Government of Canada -----Original Message----- From: Tero Kivinen via Datatracker <[email protected] <mailto:[email protected]> > Sent: October 8, 2025 3:45 AM To: [email protected] <mailto:[email protected]> ; [email protected] <mailto:[email protected]> ; [email protected] <mailto:[email protected]> Subject: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-pqc-auth-04 (Ends 2025-10-22) Subject: WG Last Call: draft-ietf-ipsecme-ikev2-pqc-auth-04 (Ends 2025-10-22) This message starts a 2-week WG Last Call for this document. Abstract: Signature-based authentication methods are utilized in IKEv2 [RFC7296]. The current version of the Internet Key Exchange Version 2 (IKEv2) protocol supports traditional digital signatures. This document specifies a generic mechanism for integrating post- quantum cryptographic (PQC) digital signature algorithms into the IKEv2 protocol. The approach allows for seamless inclusion of any PQC signature scheme within the existing authentication framework of IKEv2. Additionally, it outlines how Module-Lattice-Based Digital Signatures (ML-DSA) and Stateless Hash-Based Digital Signatures (SLH- DSA), can be employed as authentication methods within the IKEv2 protocol, as they have been standardized by NIST. File can be retrieved from: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-pqc-auth/ <https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-pqc-auth/> Please review and indicate your support or objection to proceed with the publication of this document by replying to this email keeping [email protected] <mailto:[email protected]> in copy. Objections should be motivated and suggestions to resolve them are highly appreciated. Authors, and WG participants in general, are reminded again of the Intellectual Property Rights (IPR) disclosure obligations described in BCP 79 [1]. Appropriate IPR disclosures required for full conformance with the provisions of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any. Sanctions available for application to violators of IETF IPR Policy can be found at [3]. Thank you. [1] https://datatracker.ietf.org/doc/bcp78/ <https://datatracker.ietf.org/doc/bcp78/> [2] https://datatracker.ietf.org/doc/bcp79/ <https://datatracker.ietf.org/doc/bcp79/> [3] https://datatracker.ietf.org/doc/rfc6701/ <https://datatracker.ietf.org/doc/rfc6701/> _______________________________________________ IPsec mailing list -- [email protected] <mailto:[email protected]> To unsubscribe send an email to [email protected] <mailto:[email protected]> _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
