Internet X.509 Public Key Infrastructure - Algorithm Identifiers for the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM)
draft-ietf-lamps-kyber-certificates-11

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>, debcooley1@gmail.com, draft-ietf-lamps-kyber-certificates@ietf.org, housley@vigilsec.com, lamps-chairs@ietf.org, rfc-editor@rfc-editor.org, spasm@ietf.org
Subject: Protocol Action: 'Internet X.509 Public Key Infrastructure - Algorithm Identifiers for the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM)' to Proposed Standard (draft-ietf-lamps-kyber-certificates-11.txt)

The IESG has approved the following document:
- 'Internet X.509 Public Key Infrastructure - Algorithm Identifiers for
   the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM)'
  (draft-ietf-lamps-kyber-certificates-11.txt) as Proposed Standard

This document is the product of the Limited Additional Mechanisms for PKIX
and SMIME Working Group.

The IESG contact persons are Paul Wouters and Deb Cooley.

A URL of this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-lamps-kyber-certificates/

Ballot Text

Technical Summary

   The Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is a
   quantum-resistant key-encapsulation mechanism (KEM).  This document
   describes the conventions for using the ML-KEM in X.509 Public Key
   Infrastructure.  The conventions for the subject public keys and
   private keys are also described.

Working Group Summary

   There was much controversy, especially about the private key format.
   The LAMPS WG reached a place that everyone can live with the result,
   even if everyone is not happy.  That is, the document represents a
   place where all parties are equally unhappy.

   The patent situation was not addressed to the satisfaction of all parties.
   There are messages in the archive represent that summarize the
   patent situation.  Only one person has expressed concern, and the
   potential patent holder has not chosen to make an IPR disclosure.
   Despite the IPR discussion on the mail list, no one has made a third-party
   IPR disclosure.

Document Quality

   There are draft implementations which is the reason that the private key format
   discussion became so difficult.  No implementer wanted to make changes. 

   ASN.1 is used.  The ASN.1 module in Appendix A
   compiles without error.

   There is a normative downward reference to RFC 5912, which is already
   in the DOWNREF registry.

Personnel

   The Document Shepherd for this document is Russ Housley. The Responsible
   Area Director is Deb Cooley.

RFC Editor Note