On Sun, 12 Jul 2026, Stephen Farrell wrote:
The above seems sensible. IIRC 4086 was AD sponsored, which'd have been my initial take on how to process a successor, but it's quite arguable that a WG could be better now, esp since we have new fancy crypto here and there (e.g. ppm) where some new issues might arise. A WG is probably more likely to result in such issues being thought through.
A year (or two?) ago, the SEC ADs looked at having some people create a 4086bis, as we kept running into drafts that would reference 4086 but it was so outdated it was better not to reference that but instead say "use your OS secure random source". Only the SSHM WG purposefully did not include a reference to it (and I believe they wrote a few lines of text in their RFCs basically saying "just use your OS RNG, these are better that your homegrown stuff". The SEC ADs at the time didn't feel we got a good segment of volunteers with modern OS knowledge together for them to write a 4086bis, so yes perhaps a WG would be a better approach. That said, a 4086bis would mostly target people who are not very familiar with cryptographic requirements. I feel any algorithm document specification would be implemented by people who should know enough on cryptographically strong random sources to not need such sentences, and I'm perfectly fine not adding anything to either mlkem drafts. I do think this discussion is more a red herring against pure mlkem than a real argument for text being really needed into these drafts. But provided both drafts get equal treatment getting the same sentence(s) added on randomness to avoid conspiracy theories and bad faith citations of the differences, I think this is okay to do. Which does means we would have to do this quickly as the hybrid mlkem is now in the RFC Editor queue. Paul _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
