Mind if I ask what this enormous API complication would entail (beyond, say, implementing ML-DSA signatures in TLS)?
The complexity would be: * Including the code points * Including calls to the crypto engine when those point points are referenced And, well, from the TLS side, that's about it as far as I can see. If you disagree about the need, well, that's quite fine (and that is quite a reasonable viewpoint). However, we tried quite hard to make it as simple as possible for an application (in this case, TLS); it's difficut to see how it could be simpler. I'm just tired of people who dislike a proposal to automatically raise the "complexity" objection, when the complexity is really quite minimal (and zero if you decide not to implement it). ________________________________ From: Salz, Rich <[email protected]> Sent: Wednesday, April 15, 2026 10:37 AM To: [email protected] <[email protected]> Subject: [TLS] Re: Composite ML-DSA I am also opposed to composite signatures for TLS. I don’t see a need that justifies the enormous API complications that would ensue. And, frankly, much more likely to have implementation bugs for the first couple of years.
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
