Closed smyslov closed 6 months ago
RFC 7427 mandates conveying the list of signature hash algorithms supported but I don't think it is required for PQC digital signatures (e..g, ML-DSA internally performs hash of the message before generating signature, see https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.ipd.pdf and https://datatracker.ietf.org/doc/draft-ietf-lamps-dilithium-certificates/).
One possible approach could be define a new "PQ Digital Signature" authentication method and the use of SIGNATURE_HASH_ALGORITHMS can be avoided.
The list of hash functions https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#hash-algorithms includes "Identity" (no hashing). It was used for EdDSA. So, this is not a problem.
Thanks, updated text.
I'm not sure that each defined authentication method deserves its own codepoint. The current trend in the assigning IKEv2 authentication methods is to avoid per-signature-algorithm codepoins in favor of using the generic "Digital Signature" authentication method with a specific AlgorithmIdentifier, assigned to a signature algorithm in lamps WG (see RFC 7427 for details). It seems to me that PQ signature algorithms are not different from classic signature algorithm with regard of their application, thus the "Digital Signature" authentication method can also be used for them. In this case no new IANA codepoint are allocated, but the document should reference corresponding RFCs (or drafts, or other documents) that define AlgorithmIdentifiers for the algorithms defined in this draft.
Alternatively, a new "PW Digital Signature" authentication method can be defined, with a semantics similar to "Digital Signature" authentication method, but for exclusive use with PQ signature algorithms. This i just to differentiate them for policy desicions. I'm not sure this is justified, it is just a food for thoughts.