Use of ML-KEM in the Cryptographic Message Syntax (CMS)
draft-ietf-lamps-cms-kyber-13

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-cms-kyber@ietf.org, housley@vigilsec.com, lamps-chairs@ietf.org, rfc-editor@rfc-editor.org, spasm@ietf.org
Subject: Protocol Action: 'Use of ML-KEM in the Cryptographic Message Syntax (CMS)' to Proposed Standard (draft-ietf-lamps-cms-kyber-12.txt)

The IESG has approved the following document:
- 'Use of ML-KEM in the Cryptographic Message Syntax (CMS)'
  (draft-ietf-lamps-cms-kyber-12.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-cms-kyber/

Ballot Text

Technical Summary

   Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is a
   quantum-resistant key-encapsulation mechanism (KEM).  Three
   parameter sets for the ML-KEM algorithm are specified by NIST in
   FIPS 203.  In order of increasing security strength (and decreasing
   performance), these parameter sets are ML-KEM-512, ML-KEM-768, and
   ML-KEM-1024.  This document specifies the conventions for using ML-
   KEM with the Cryptographic Message Syntax (CMS) using the
   KEMRecipientInfo structure.

Working Group Summary

   There was much controversy, especially about the private key format,
   which is specified in the companion document (draft-ietf-lamps-kyber-
   certificates).  The LAMPS WG reached a place that everyone can live
   with the result, even though everyone is not happy.  That is, the two
   documents represent 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 are two normative DOWNREFs: RFC 3394 and RFC 5869.  Both are
    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