Hi Henrick, I think you and Richard actually agree, which is the interesting part.
> As an independent implementer, I would like to weigh in. I believe there > might be a misunderstanding here. > > While it is common for software libraries to implement active > Internet-Drafts, this is not a viable long-term solution. Features > backed only by a rejected, long-dead draft cannot be safely maintained > over time. > > Furthermore, while hardware isn't my primary domain, I highly doubt any > hardware manufacturer would commit resources to implementing a rejected > draft. Your point is that the RFC gives you something the code points alone don't: a stable reference that vendors and hardware makers will build on. A dead draft won't support that. Sure, I agree with all of it. But that's Richard's whole argument. Publication isn't neutral. It's the thing that turns some registry entries into products people ship. So "does the RFC drive deployment" isn't really in dispute anymore. You've argued that it does. The real question is whether we want to push deployment toward standalone ML-KEM when X25519MLKEM768 is already there, already Recommended=Y, strictly stronger, and costs almost nothing. And the module-validation case makes this worse, not better. Those deployments patch on validation timelines, not software ones. So "the RFC makes it real" is an argument for caution, not for shipping. Cheers, David Stainton Founder, Katzenpost — post-quantum mix network _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
