[lamps] Re: [EXT] Re: WG Last Call for draft-ietf-lamps-kyber-certificates-07

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

Thanks to Dan for pointing at that mailing list thread. 

Here’s what Yunlei said on May 12, 2022: 

Finally, we would like to stress again we hold all the patents only for protection against credit (not for economic reasons). We hope the above clarifications could make the situation clearer.

All my best 
Yunlei 

Thanks! 
-- 
V/R, 

Uri 

From: D. J. Bernstein <[e-mail]>
Date: Friday, January 10, 2025 at 13:51
To: [e-mail] <[e-mail]>
Subject: [EXT] [lamps] Re: WG Last Call for draft-ietf-lamps-kyber-certificates-07 

!-------------------------------------------------------------------|
This Message Is From an External Sender
This message came from outside the Laboratory.
|-------------------------------------------------------------------!

I see two BCP 79 compliance problems in this draft. The same comments
apply to draft-ietf-lamps-cms-kyber-08.


1. As background, there are known patent claims regarding Kyber. NIST
has reportedly signed patent licenses regarding patents US9094189
(Gaborit and Aguilar-Melchor) and US9246675 (Ding). However, another
patent holder wrote in

https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/Fm4cDfsx65s/m/F63mixuWBAAJ <https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/Fm4cDfsx65s/m/F63mixuWBAAJ>

that "Kyber is covered by our patents" including "the two patents
mentioned in the KCL proposal". I've seen no evidence of a royalty-free
license for those patents, such as CN107566121A (which was filed a month
before the publication of "NewHope without reconciliation", Kyber's
direct predecessor).

Even for the GAM and Ding patents, the complete signed licenses don't
appear to be available to the public. The posting

https://web.archive.org/web/20221130033932/https://csrc.nist.gov/csrc/media/Projects/post-quantum-cryptography/documents/selected-algos-2022/nist-pqc-license-summary-and-excerpts.pdf <https://web.archive.org/web/20221130033932/https:/csrc.nist.gov/csrc/media/Projects/post-quantum-cryptography/documents/selected-algos-2022/nist-pqc-license-summary-and-excerpts.pdf>

says that it contains "relevant language (with modifications for
readability)" from the licenses; this provides no guarantees of
completeness and accuracy.

Furthermore, what has been posted (see previous link) appears to
indicate that the US9246675 license excludes "any modification,
extension, or derivation of the parameters of the PQC ALGORITHM".


2. BCP 79 says the following: "An IETF consensus has developed that no
mandatory-to-implement security technology can be specified in an IETF
specification unless it has no known IPR claims against it or a
royalty-free license is available to implementers of the specification."

One can't implement draft-ietf-lamps-kyber-certificates-07 without
implementing Kyber. The Zhao claim that "Kyber is covered by our
patents" is a known IPR claim regarding Kyber. Consequently, before
becoming an IETF RFC, the draft should be modified to allow alternatives
to Kyber.

The only other approach would be for the draft to invoke the exception
procedure from BCP 79: "It is possible to specify such a technology in
violation of this principle if there is a very good reason to do so and
if that reason is documented and agreed to through IETF consensus." I
haven't seen IETF-wide notification of a proposal to violate this BCP 79
principle, and I'm also not aware of a good reason to do so, let alone a
"very good reason". There are patent claims regarding Kyber, so any IETF
specification using Kyber should also include alternatives.


3. BCP 79 also says the following: "The IETF must have change control
over the technology described in any Standards Track IETF Documents in
order to fix problems that may be discovered or to produce other
derivative works."

BCP 79 goes on to say that it isn't prohibiting proprietary cryptography
but requires negotiations with the patent holders to ensure change
control:

In some cases, the developer of patented or otherwise controlled
technology may decide to hand over to the IETF the right to evolve
the technology (a.k.a., "change control"). The implementation of an
agreement between the IETF and the developer of the technology can be
complex. (See [RFC1790] and [RFC2339] for examples.)

Note that there is no inherent prohibition against a Standards Track
IETF Document making a normative reference to proprietary technology.
For example, a number of IETF standards support proprietary
cryptographic transforms.

The change-control rule per se has no exceptions. In the absence of
change control, a draft cannot go on the standards track.

Even if we assume that

https://web.archive.org/web/20221130033932/https://csrc.nist.gov/csrc/media/Projects/post-quantum-cryptography/documents/selected-algos-2022/nist-pqc-license-summary-and-excerpts.pdf <https://web.archive.org/web/20221130033932/https:/csrc.nist.gov/csrc/media/Projects/post-quantum-cryptography/documents/selected-algos-2022/nist-pqc-license-summary-and-excerpts.pdf>

accurately reflects the actual signed licenses, it doesn't assign Kyber
change control from the US9246675 patent holder to IETF. Modifications
to produce derivative works, for example to fix problems that may be
discovered, wouldn't be allowed. The patent holder would be free to
charge IETF arbitrary amounts to allow such modifications. This is the
type of trap that the change-control requirement is designed to avoid.


---D. J. Bernstein

_______________________________________________
Spasm mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]