On 03.02.25 22:13, Scott Fluhrer (sfluhrer) wrote:
Well, based on the existing RFCs, there are multiple ways of doing this (and hence we need to have something which says "this is the way for ML-DSA"). In addition to the approach I suggested, we have RFC 8420 (EdDSA), which also isn't 'straight-hash-and-sign'. Now, if the working group decides the RFC 8420 approach is the way to go, I have no problem with that. My aim was to spell out an approach that would fit the cleanest into the existing architecture and implementations. Now, if people who have existing implementations disagree (and for example, say the RFC 8420 way of doing things is better), I'll change things.
The strongSwan project is strongly in favor of using the "Identity" Hash Identifier as defined by RFC 8420 in conjunction with ML-DSA Pure Signing Mode. We are not too enthusiastic about prepending an "IKEv2 AUTH" context string in ML-DSA signatures because the ML-DSA certificates used for the signatures will most probably not have any context string in the issuing CA's signature. The configuring multiple context strings in a single application would become quite complex. ====================================================================== Andreas Steffen andreas.stef...@strongswan.org strongSwan - the Open Source VPN Solution! www.strongswan.org strongSec GmbH, 8952 Schlieren (Switzerland) ====================================================================== _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
