On Mon, 22 Sep 2025, Scott Fluhrer (sfluhrer) wrote:
[ Speaking as libreswan, an IKEv2 vendor ]
While this works, that is not the only possible option (and this is what I
would like to get people's opinion on). Here are two obvious alternative
options:
* ML-DSA and SLH-DSA also have a 'prehash' option, which is designed
specifically for externally hashed data (which is what we have in this case).
However, there
are several possible practical drawbacks (whether it will be commonly
implemented and that uses different certificate OIDs which may not be widely
implemented)
that caused us to not select this option.
* EdDSA has a similar constraint that it is also does not use a
'hash-and-sign' paradigm internally - RFC 8420 provides an alternative method
(avoid the IKEv2
hash operations entirely and present the 'signed octets' string to the
EdDSA operation); ML-DSA and SLH-DSA would both fit cleanly into this.
However, I expect
that implementing this on IKE implementations that do not already support
RFC 8420 would be more work.
We have not implemented 8420 yet as we were waiting (at the time) for
crpyto library updates. We do want to add 8420 support, and so we don't
mind similar constructs for ML-DSA (or SLH-DSA). That is, we are okay
with whatever the real crytographers are okay with. But we would like
to avoid any certificate OID complexity.
Paul
_______________________________________________
IPsec mailing list -- [email protected]
To unsubscribe send an email to [email protected]
