2026-03-26 03:50 GMT-07:00 Simon Josefsson
<[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]
