Complaint regarding BCP 79 violations in the LAMPS WG (D. J. Bernstein) - 2025-05-01
Response - 2025-05-22
Summary
The IESG received an appeal from Daniel Bernstein on May 1, 2025 for the decisions of the LAMPS Working Group (“WG”) Chairs and the responsible Area Director (“AD”) that declared WG consensus on draft-ietf-lamps-kyber-certificates and draft-ietf-lamps-cms-kyber. The stated reasons for this appeal are perceived IPR issues and presumed restrictions on accepting technologies that might be covered by discriminatory IPR.
The IESG has concluded that there were no process failures by the WG, WG Chairs, or the responsible AD.
The appeal is denied.
Appeal response from the IESG
The IESG has reviewed the matter and affirms the approach taken by the LAMPS WG Chairs and the responsible Area Director.
Deb Cooley, responsible AD for the LAMPS WG, did not take part in the processing of this appeal by the IESG.
IPR claim
IESG Understanding of Appellant’s Position
The appellant asserts that there exists an IPR claim rendering the Module-Lattice-Based Key-Encapsulation Mechanism (hereinafter “ML-KEM”), a cryptographic technology, ineligible for standardization under the provisions of BCP 79, yet draft-ietf-lamps-kyber-certificates and draft-ietf-lamps-cms-kyber have been advanced to the IESG for publication. The appellant cites Section 7 of RFC8179/BCP79, “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.”
Timeline of Key Events
| draft-ietf-lamps-kyber-certificates | draft-ietf-lamps-cms-kyber |
|---|---|
| 10-Jan-2025 – both documents start WG Last Call review | 10-Jan-2025 – both documents start WG Last Call review |
| 10-Jan-2025 – appellant raised potential IPR concerns with draft-ietf-lamps-kyber-certificates as WG Last Call feedback. This same feedback is stated to apply to draft-ietf-lamps-cms-kyber (also in WG Last Call) | 10-Jan-2025 – appellant raised potential IPR concerns with draft-ietf-lamps-kyber-certificates as WG Last Call feedback. This same feedback is stated to apply to draft-ietf-lamps-cms-kyber (also in WG Last Call) |
| 17-Jan-2025 – the LAMPS WG chair requested during the ongoing WG Last Call that “if this information [from the appellant on potential IPR] changes a view that you have already expressed during this WG Last Call, please post a follow-up message”. | |
| 16-April-2025 – the appellant raises that their potential IPR claim feedback was not addressed in draft-ietf-lamps-kyber-certificates-09. | |
| 17-Apr-2025 – LAMPS WG chair declares conclusion of the WG Last Call on draft-ietf-lamps-kyber-certificates and that there is consensus to publish 17-Apr-2025 – LAMPS WG Chair places draft-ietf-lamps-kyber-certificates into the “Publication Requested” state | |
| 18-Apr-2025 – the appellant appeals to the responsible AD on the conclusion of the WG Last Call | |
| 22-Apr-2025 – LAMPS WG chair declares a conclusion of the WG Last Call on draft-ietf-lamps-cms-kyber and that there is consensus to publish 22-Apr-2025 – LAMPS WG Chair places draft-ietf-lamps-cms-kyber into the “Publication Requested” state | |
| 23-Apr-2025 – the appellant appeals to the responsible AD on the advancement of this document, and suggests processing this dispute concurrently with draft-ietf-lamps-kyber-certificates | |
| 25-Apr-2025 – the responsible AD considers the appeal on both documents and responds by declining the appeal | 25-Apr-2025 – the responsible AD considers the appeal on both documents and responds by declining the appeal |
IESG Response
Section 5.1.3 of RFC8179 describes the IETF processes for handling third party IPR disclosures. Section 5.3 of RFC8179 provides normative guidance on the mechanism for disclosure of IPR for the IETF to consider. The IESG has confirmed that at the time of this appeal response, neither the appellant, nor anyone else, filed an IPR disclosure for ML-KEM linked to draft-ietf-lamps-kyber-certificates or draft-ietf-lamps-cms-kyber in the datatracker.
Despite the absence of a formal IPR disclosure, the IESG found that this potential IPR claim was raised in the LAMPS WG during the WG Last Calls for both documents, to include the WG Chair explicitly highlighting it. Even with awareness of this claim, the WG still found rough consensus to advance these documents to publication consistent with the WG processes for Last Call in Sections 3 and 7.4 of RFC2418 and Section 7 of RFC8179.
In particular, the appeal stated that the WG Chair's conclusion on the appellant being the only one to have this potential IPR concern was wrong, as there was one more participant that had "concerns" per this WG Last Call feedback. While the appellant is correct that this participant showed "concern", the participant nevertheless indicated support for the document going forward.
Per Section 2 of RFC8179, the IESG repeats that “the IETF will make no determination about the validity of any particular IPR claim.” Furthermore, “the IETF, following normal processes, can decide to use technology for which IPR disclosures have been made if it decides that such a use is warranted.”
While no formal IPR claim was filed to consider, the LAMPS WG was informed of this potential IPR claim, and still found rough consensus during WG Last Call to proceed with publication.
The IESG also notes that the handling of this potential IPR claim was documented in the shepherd write-up of draft-ietf-lamps-kyber-certificates and the shepherd write-ups of draft-ietf-lamps-cms-kyber. As such, it will be available for review and consideration during the IETF Last Call.
“Mandatory-To-Implement” claim
IESG Understanding of Appellant’s Position
The appellant asserts that, since ML-KEM is a required dependency of draft-ietf-lamps-kyber-certificates and draft-ietf-lamps-cms-kyber, it renders ML-KEM mandatory-to-implement (MTI). As change control of ML-KEM is the purview of US NIST, the appellant asserts that these documents violate Section 7 of RFC8179/BCP79, which states “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.”
IESG Response
Draft-ietf-lamps-kyber-certificates and draft-ietf-lamps-cms-kyber specify optional extensions to the Internet X.509 Public Key Infrastructure Certificate Profile (X.509) and Cryptographic Message Syntax (CMS). While both documents cite ML-KEM as a normative reference, the concepts of “mandatory-to-implement” and normative reference are not synonyms. Citing ML-KEM normatively does not bestow any sort of mandatory status or otherwise compel any developer to implement, enable, or otherwise support ML-KEM to be able to use X.509 or CMS. Put more simply, these documents say, in effect: If one is going to add ML-KEM support to an X.509/CMS implementation, this is the IETF’s standard method of doing so. The decision explicit in the first word of that statement (“If”) contradicts any notion of “mandatory”, and what is being standardized is the link between the X.509/CMS and ML-KEM, not ML-KEM itself.
Requiring change control of every normative reference would essentially mean the IETF could not have a normative reference to a document it did not author. Section 8 of RFC 8179 explicitly states that “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.”
Notwithstanding the conclusions of the IPR claims section, this claim fails on its merits.
Background Analysis of the Documents
Draft-ietf-lamps-kyber-certificates specifies conventions for using ML-KEM in X.509 Public Key Infrastructure. Draft-ietf-lamps-cms-kyber specifies conventions for using ML-KEM with the CMS. Collectively they define these conventions by building on prior Public Key Infrastructure (PKIX) and CMS specifications such as RFC3565, RFC5083, RFC5280, RFC5912, RFC5652, RFC5958, and RFC9629.
These PKIX RFCs and those that update them do not provide normative language on which algorithm is mandatory to implement. This lack of guidance makes implementing ML-KEM optional in the X.509 Public Key Infrastructure.
Additionally, the referenced CMS specifications do not provide normative language on which algorithm is mandatory to implement. In particular, the base CMS specification, Section 1.1.2 of RFC5652 states that “This specification does not require the implementation of any particular algorithms. Rather, protocols that rely on the CMS are expected to choose appropriate algorithms for their environment.” Furthermore, Section 2 of draft-ietf-lamps-cms-kyber explicitly begins with “the ML-KEM algorithm MAY be employed …” and then enumerates the possible data structure in CMS. This guidance makes implementing ML-KEM optional for CMS.
Standing of a Blog Post
The IESG notes that the appellant cites a sentence from an IETF Administration LLC blog post in several forums, including this appeal: “IETF activities are conducted with extreme transparency, in public forums”. The appellant appears to interpret that text as normative guidance which requires any parties discussing their request to do so only in public forums, and prohibiting private discussion.
The IESG is clarifying that this interpretation is incorrect. This blog post is a narrative summary of existing RFCs speaking in generalities, and provides no new normative guidance for the IETF. If there is specific concern about normative communication practices, please cite an appropriate RFC.
Conclusions
The IESG determines that:
- The potential IPR claim described in this appeal was raised in the LAMPS WG, considered during WG Last Call, and the WG chairs and responsible AD appropriately declared rough consensus from the WG Last Calls that enabled advancement of drafts.
- The “mandatory-to-implement” claim raised in this appeal is not applicable to these documents.
The appeal is denied.