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

[Russ Housley <[e-mail]>]

Dan:

1.  Thanks for the background on this matter; however, I must point out that there are no IPR disclosures, including third-party IPR disclosures, against this document.  See:

	https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-lamps-kyber-certificates

You seem to be very familiar with the IETF IPR-related documents, but for other readers, I will point out that Section 5.1.3 of BCP 79 covers third-party disclosures.

When the IETF Secretariat has receives a notification under Section 5.1.3 of the existence of non-participant IPR that potentially Covers a technology under discussion at IETF or which is the subject of an IETF Document, the IETF Secretariat shall promptly publish such notification and will request that the identified third party make an IPR disclosure in accordance with the provisions of Section 5 of BCP 79.

2.  This is not a mandator-to-implement algorithm.  If one chooses to implement this specification, then that implementer will obviously need to implement ML-KEM.  Implementation of this specification is completely voluntary, even if it is published as a standards-track RFC.

3.  The IETF does have change control over this specification, but it does not have change control over ML-KEM.  If a problem is ever discovered with ML-KEM, then the IETF will have two choices.  The IETF can work with NIST to resolve the problem, or the IETF can deprecate the use of ML-KEM.  RFC 6649 is an example of the later, where DES (which was also a NIST algorithm) is deprecated for use in Kerberos.

Russ


> On Jan 10, 2025, at 1:50 PM, D. J. Bernstein <[e-mail]> wrote:
> 
> 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
> 
> 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
> 
> 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
> 
> 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]