++ On Thu, Mar 26, 2026, 7:52 AM Filippo Valsorda <[email protected]> wrote:
> 2026-03-26 03:50 GMT-07:00 Simon Josefsson <simon= > [email protected]>: > > There are many other reasonable positions to end up in that are > different from the one above. A simple approach of "The ML-KEM patents > are nonsense and I don't care about them" solves many concerns, and may > be the most pragmatic and common opinion right now. > > > I reiterate that I strongly support this document change for other > reasons, but to avoid tedious discussions down the line, I want to suggest > another position: "the patent license covers ML-KEM as specified in FIPS > 204 and if the specification doesn't say anything about key reuse, just > like it doesn't say anything about e.g. the architecture you run it on, > then it's out of scope and you can do whatever you like without reading tea > leaves." > > The alternative interpretation that key reuse somehow is not covered by > the license reads to me as engineer-minded reverse-malicious compliance > <https://en.wikipedia.org/wiki/Malicious_compliance> of the likes we see > a lot with FIPS 140-3. (Many times I have read that something was > categorically not allowed by FIPS 140-3, and then I read the documents or > asked NIST and neither cared, and then I got the lab to sign off on it.) > The law does not generally work like engineers expect, and until a patent > lawyer tells us key reuse poses actual litigation risk, we would do better > not to come up with legal theories (and commit them to writing—in > public!—which every lawyer *will* advise you against). > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
