Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) for COSE
draft-ietf-jose-pqc-kem-06

COSE                                                            T. Reddy
Internet-Draft                                               A. Banerjee
Intended status: Standards Track                                   Nokia
Expires: 7 January 2027                                    H. Tschofenig
                                                                UniBw M.
                                                             6 July 2026

      Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) for COSE
                       draft-ietf-jose-pqc-kem-06

Abstract

   This document describes conventions for using Post-Quantum Key
   Encapsulation Mechanisms (PQ-KEMs) with CBOR Object Signing and
   Encryption (COSE).

About This Document

   This note is to be removed before publishing as an RFC.

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-ietf-jose-pqc-kem/.

   Discussion of this document takes place on the cose Working Group
   mailing list (mailto:cose@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/cose/.  Subscribe at
   https://www.ietf.org/mailman/listinfo/cose/.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 7 January 2027.

Reddy, et al.            Expires 7 January 2027                 [Page 1]
Internet-Draft               PQ KEM for COSE                   July 2026

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
     2.1.  Key Encapsulation Mechanisms  . . . . . . . . . . . . . .   4
   3.  Design Rationales . . . . . . . . . . . . . . . . . . . . . .   5
   4.  KEM PQC Algorithms  . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  ML-KEM  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  PQ-KEM Encapsulation  . . . . . . . . . . . . . . . . . .   6
     4.3.  PQ-KEM Decapsulation  . . . . . . . . . . . . . . . . . .   6
   5.  KDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     5.1.  Key Derivation  . . . . . . . . . . . . . . . . . . . . .   7
   6.  Post-Quantum KEM in COSE  . . . . . . . . . . . . . . . . . .   7
     6.1.  Direct Key Agreement  . . . . . . . . . . . . . . . . . .   8
     6.2.  Key Agreement with Key Wrap . . . . . . . . . . . . . . .   8
   7.  COSE Ciphersuite Registration . . . . . . . . . . . . . . . .   9
   8.  Use of AKP Key Type for PQC KEM Keys in COSE  . . . . . . . .   9
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
     10.1.  COSE Algorithms Registrations  . . . . . . . . . . . . .  11
     10.2.  COSE Elliptic Curves Registrations . . . . . . . . . . .  12
       10.2.1.  ML-KEM-512 . . . . . . . . . . . . . . . . . . . . .  13
       10.2.2.  ML-KEM-768 . . . . . . . . . . . . . . . . . . . . .  13
       10.2.3.  ML-KEM-1024  . . . . . . . . . . . . . . . . . . . .  13
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  14
   References  . . . . . . . . . . . . . . . . . . . . . . . . . . .  14
     Normative References  . . . . . . . . . . . . . . . . . . . . .  14
     Informative References  . . . . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

Reddy, et al.            Expires 7 January 2027                 [Page 2]
Internet-Draft               PQ KEM for COSE                   July 2026

1.  Introduction

   Quantum computing is no longer perceived as a consequence of
   computational sciences and theoretical physics.  Considerable
   research efforts and enormous corporate and government funding for
   the development of practical quantum computing systems are being
   invested currently.  As such, as quantum technology advances, there
   is the potential for future quantum computers to have a significant
   impact on current cryptographic systems.

   Researchers have developed Post-Quantum Key Encapsulation Mechanisms
   (PQ-KEMs) to provide secure key establishment resistant against an
   adversary with access to a quantum computer.

   The National Institute of Standards and Technology (NIST) has
   standardized ML-KEM as a post-quantum key encapsulation mechanism in
   [FIPS203].  This document specifies how ML-KEM is used to protect the
   confidentiality of content encrypted with COSE against adversaries
   with access to quantum computers.

   Although this mechanism could thus be used with any PQ-KEM, this
   document focuses on Module-Lattice-based Key Encapsulation Mechanisms
   (ML-KEMs).  ML-KEM is a one-pass (store-and-forward) cryptographic
   mechanism for an originator to securely send keying material to a
   recipient using the recipient's ML-KEM public key.  Three parameters
   sets for ML-KEMs are specified by [FIPS203].  In order of increasing
   security strength (and decreasing performance), these parameter sets
   are ML-KEM-512, ML-KEM-768, and ML-KEM-1024.

2.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   This document makes use of the terms defined in
   [I-D.ietf-pquip-pqt-hybrid-terminology].  The following terms are
   repeatedly used in this specification:

   *  KEM: Key Encapsulation Mechanism

   *  PQ-KEM: Post-Quantum Key Encapsulation Mechanism

   *  CEK: Content Encryption Key

   *  ML-KEM: Module-Lattice-based Key Encapsulation Mechanism

Reddy, et al.            Expires 7 January 2027                 [Page 3]
Internet-Draft               PQ KEM for COSE                   July 2026

   For the purposes of this document, it is helpful to be able to divide
   cryptographic algorithms into two classes:

   "Traditional Algorithm": An asymmetric cryptographic algorithm based
   on integer factorization, finite-field discrete logarithms, or
   elliptic-curve discrete logarithms.  In the context of COSE, examples
   of traditional key exchange algorithms include Ephemeral-Static (ES)
   DH and Static-Static (SS) DH [RFC9052].

   "Post-Quantum Algorithm": An asymmetric cryptographic algorithm that
   is believed to be secure against attacks using quantum computers as
   well as classical computers.  Post-quantum algorithms can also be
   called quantum-resistant or quantum-safe algorithms.  Examples of
   Post-Quantum Algorithm include ML-KEM.

2.1.  Key Encapsulation Mechanisms

   For the purposes of this document, we consider a Key Encapsulation
   Mechanism (KEM) to be any asymmetric cryptographic scheme comprised
   of algorithms satisfying the following interfaces [PQCAPI].

   *  def kemKeyGen() -> (pk, sk)

   *  def kemEncaps(pk) -> (ct, ss)

   *  def kemDecaps(ct, sk) -> ss

   where pk is public key, sk is secret key, ct is the ciphertext
   representing an encapsulated key, and ss is shared secret.

   This document uses the COSE header parameter ek to carry the KEM
   ciphertext ct produced by ML-KEM encapsulation.  This differs from
   the terminology used in FIPS 203 and [RFC9936], where ek denotes the
   public ML-KEM encapsulation key.  In this document, the public ML-KEM
   encapsulation key is represented as the public component of an AKP
   key, while the COSE header parameter ek carries the encapsulated key,
   namely the KEM ciphertext ct.

   KEMs are typically used in cases where two parties, hereby refereed
   to as the "encapsulater" and the "decapsulater", wish to establish a
   shared secret via public key cryptography, where the decapsulater has
   an asymmetric key pair and has previously shared the public key with
   the encapsulater.

Reddy, et al.            Expires 7 January 2027                 [Page 4]
Internet-Draft               PQ KEM for COSE                   July 2026

3.  Design Rationales

   Sections 8.5.4 and 8.5.5 of COSE [RFC9052] define Direct Key
   Agreement and Key Agreement with Key Wrap, respectively.  This
   document specifies the use of PQ-KEMs in these two modes.  In Direct
   Key Agreement mode, the derived shared secret is used as the content
   encryption key (CEK).  In Key Agreement with Key Wrap mode, the
   derived shared secret is used as a key-encryption key to wrap the
   CEK.

   Key Agreement with Key Wrap supports efficient encryption for
   multiple recipients: the content is encrypted once with the CEK, and
   an individually wrapped CEK is provided for each recipient.

   It is essential to note that in the PQ-KEM, one needs to apply
   Fujisaki-Okamoto [FO] transform or its variant [HHK] on the PQC KEM
   part to ensure that the overall scheme is IND-CCA2 secure, as
   mentioned in [I-D.ietf-tls-hybrid-design].  The FO transform is
   performed using the KDF such that the PQC KEM shared secret achieved
   is IND-CCA2 secure.  As a consequence, one can re-use PQC KEM public
   keys but there is an upper bound that must be adhered to.

   During the transition from traditional to post-quantum algorithms,
   protocols may need to combine both types of algorithms.  The use of
   hybrid post-quantum KEMs with HPKE and COSE is outside the scope of
   this document.

4.  KEM PQC Algorithms

   At time of writing, NIST have standardized three PQC algorithms, with
   more expected to be standardised in the future ([NISTFINAL]).  These
   algorithms are not necessarily drop-in replacements for traditional
   asymmetric cryptographic algorithms.  For instance, RSA [RSA] and ECC
   [RFC6090] can be used as both a key encapsulation method (KEM) and as
   a signature scheme, whereas there is currently no post-quantum
   algorithm that can perform both functions.

4.1.  ML-KEM

   ML-KEM offers several parameter sets with varying levels of security
   and performance trade-offs.  This document specifies the use of the
   ML-KEM algorithm at three security levels: ML-KEM-512, ML-KEM-768,
   and ML-KEM-1024.  ML-KEM key generation, encapsulation and
   decaspulation functions are defined in [FIPS203].  The main security
   property for KEMs standardized in the NIST Post-Quantum Cryptography
   Standardization Project is indistinguishability under adaptive chosen
   ciphertext attacks (IND-CCA2) (see Section 10.2 of
   [I-D.ietf-pquip-pqc-engineers]).  The public/private key sizes,

Reddy, et al.            Expires 7 January 2027                 [Page 5]
Internet-Draft               PQ KEM for COSE                   July 2026

   ciphertext key size, and PQ security levels of ML-KEM are detailed in
   Section 12 of [I-D.ietf-pquip-pqc-engineers].

4.2.  PQ-KEM Encapsulation

   The encapsulation process is as follows:

   1.  Generate an inital shared secret SS' and the associated
       ciphertext CT using the KEM encapsulation function and the
       recipient's public key recipPubKey.

             (SS', CT) = kemEncaps(recipPubKey)

   1.  Derive a final shared secret SS of length SSLen bytes from the
       initial shared secret SS' using the underlying key derivation
       function:

             SS = KDF(SS', SSLen)

   In Direct Key Agreement mode, the output of the KDF MUST have the key
   length required by the content encryption algorithm used by the
   COSE_Encrypt structure.  In Key Agreement with Key Wrap mode, the
   output of the KDF MUST have the key length required by the key wrap
   algorithm selected by the recipient algorithm.  For the algorithms
   defined in this specification, the KDF output length is 128 bits for
   ML-KEM-512+A128KW, 192 bits for ML-KEM-768+A192KW, and 256 bits for
   ML-KEM-1024+A256KW.

   When Direct Key Agreement is employed, SS is the CEK.  When Key
   Agreement with Key Wrapping is employed, SS is the key-encryption key
   used with AES Key Wrap to wrap the CEK; SS is not the CEK.

4.3.  PQ-KEM Decapsulation

   The decapsulation process is as follows:

   1.  Decapsulate the ciphertext CT using the KEM decapsulation
       function and the recipient's private key to retrieve the initial
       shared secret SS':

             SS' = kemDecaps(recipPrivKey, CT)

If the decapsulation operation outputs an error, output "decryption error", and stop.

   1.  Derive the final shared secret SS of length SSLen bytes from the
       inital secret SS' using the underlying key derivation function:

             SS = KDF(SS', SSLen)

Reddy, et al.            Expires 7 January 2027                 [Page 6]
Internet-Draft               PQ KEM for COSE                   July 2026

5.  KDF

5.1.  Key Derivation

   The key derivation for COSE is performed using KMAC as defined in
   NIST SP 800-108r1-upd1 [SP-800-108r1].  The KMAC(K, X, L, S)
   parameters are instantiated as follows:

   *  K: the input key-derivation key.  In this document this is the
      initial shared secret (SS') outputted from the kemEncaps() or
      kemDecaps() functions.

   *  X: The context structure defined in Section 5.2 of [RFC9053],
      excluding the PartyUInfo and PartyVInfo fields.  PartyUInfo is
      omitted because sender authentication is not available in PQ-KEMs.
      PartyVInfo is omitted because the recipient's identity is bound to
      the public key used for encapsulation.  If mutually known private
      information is included, the sender and recipient MUST agree out
      of band to include it as SuppPrivInfo, as defined in
      [NIST.SP.800-56Ar3].

   *  L: length of the output key in bits.  In Direct Key Agreement
      mode, L is set to the key length required by the content
      encryption algorithm.  In Key Agreement with Key Wrapping mode, L
      is set to the key length required by the key wrap algorithm; for
      ML-KEM-512+A128KW, ML-KEM-768+A192KW, and ML-KEM-1024+A256KW this
      is 128, 192, and 256 bits, respectively.

   *  S: the optional customization label.  In this document this
      parameter is unused, that is it is the zero-length string "".

   For all security levels of ML-KEM, KMAC256 is used.

6.  Post-Quantum KEM in COSE

   This specification supports two uses of PQ-KEM in COSE, namely

   *  PQ-KEM in a Direct Key Agreement mode.

   *  PQ-KEM in a Key Agreement with Key Wrap mode.

   In both modes, the COSE header parameter ek, defined in Section 7.2
   of [I-D.ietf-cose-hpke], is used to convey the ciphertext ct output
   by the PQ-KEM encapsulation algorithm.

Reddy, et al.            Expires 7 January 2027                 [Page 7]
Internet-Draft               PQ KEM for COSE                   July 2026

6.1.  Direct Key Agreement

   The CEK will be generated using the process explained in Section 4.2.
   Subsequently, the plaintext will be encrypted using the CEK.  The
   resulting ciphertext is either included in the COSE_Encrypt or is
   detached.  If a payload is transported separately then it is called
   "detached content".  A nil CBOR object is placed in the location of
   the ciphertext.  See Section 5 of [RFC9052] for a description of
   detached payloads.

   The COSE_Recipient structure for the recipient is organized as
   follows:

   *  The sender MUST set the 'alg' parameter to indicate the use of the
      PQ-KEM algorithm.

   *  This document RECOMMENDS the use of the 'kid' parameter (or other
      parameters) to explicitly identify the recipient public key used
      by the sender.  If the COSE_Encrypt contains the 'kid' then the
      recipient may use it to select the appropriate private key.

6.2.  Key Agreement with Key Wrap

   With the two layer structure the PQ-KEM information is conveyed in
   the COSE_recipient structure, i.e. one COSE_recipient structure per
   recipient.

   In this approach the following layers are involved:

   *  Layer 0 (corresponding to the COSE_Encrypt structure) contains the
      content (plaintext) encrypted with the CEK.  This ciphertext may
      be detached, and if not detached, then it is included in the
      COSE_Encrypt structure.

   *  Layer 1 (corresponding to a recipient structure) contains
      parameters needed for PQ-KEM to generate a shared secret used to
      encrypt the CEK.  This layer conveys the encrypted CEK in the
      "ciphertext" field (Section 5.1 of [RFC9052]).  The unprotected
      header MAY contain the kid parameter to identify the static
      recipient public key the sender has been using with PQ-KEM.

   This two-layer structure is used to encrypt content that can also be
   shared with multiple parties at the expense of a single additional
   encryption operation.  As stated above, the specification uses a CEK
   to encrypt the content at layer 0.

Reddy, et al.            Expires 7 January 2027                 [Page 8]
Internet-Draft               PQ KEM for COSE                   July 2026

7.  COSE Ciphersuite Registration

   All security levels of ML-KEM internally use SHA3-256, SHA3-512,
   SHAKE128, and SHAKE256.  This internal usage influences the selection
   of the KDF described in this document.

   ML-KEM-512 MUST be used with a KDF capable of producing a key with at
   least 128 bits of security and, in Key Agreement with Key Wrap mode,
   with a key wrap algorithm having a key length of at least 128 bits.

   ML-KEM-768 MUST be used with a KDF capable of producing a key with at
   least 192 bits of security and, in Key Agreement with Key Wrap mode,
   with a key wrap algorithm having a key length of at least 192 bits.

   ML-KEM-1024 MUST be used with a KDF capable of producing a key with
   at least 256 bits of security and, in Key Agreement with Key Wrap
   mode, with a key wrap algorithm having a key length of at least 256
   bits.

   Figure 1 lists the COSE algorithm values for the PQ-KEM ciphersuites
   defined by this document.

+===============================+=========+===================================+=============+
| Name                          | COSE ID | Description                       | Recommended |
+===============================+=========+===================================+=============+
| ML-KEM-512                    | TBD1    | ML-KEM-512                        | No          |
+-------------------------------+---------+-----------------------------------+-------------+
| ML-KEM-768                    | TBD2    | ML-KEM-768                        | No          |
+-------------------------------+---------+-----------------------------------+-------------+
| ML-KEM-1024                   | TBD3    | ML-KEM-1024                       | No          |
+-------------------------------+---------+-----------------------------------+-------------+
| ML-KEM-512+A128KW             | TBD4    | ML-KEM-512 + AES128KW             | No          |
+-------------------------------+---------+-----------------------------------+-------------+
| ML-KEM-768+A192KW             | TBD5    | ML-KEM-768 + AES192KW             | No          |
+-------------------------------+---------+-----------------------------------+-------------+
| ML-KEM-1024+A256KW            | TBD6    | ML-KEM-1024 + AES256KW            | No          |
+-------------------------------+---------+-----------------------------------+-------------+

                 Figure 1: COSE PQ-KEM Ciphersuites.

8.  Use of AKP Key Type for PQC KEM Keys in COSE

   The "AKP" (Algorithm Key Pair) key type, defined in
   [I-D.ietf-cose-dilithium], is used to represent PQC KEM keys in COSE.
   A COSE_Key with "kty" set to "AKP" represents a PQC KEM key pair.
   The public key is carried in the "pub" parameter.  If included, the
   private key is carried in the "priv" parameter.  Both parameters are
   byte strings containing the raw algorithm-specific key material.

Reddy, et al.            Expires 7 January 2027                 [Page 9]
Internet-Draft               PQ KEM for COSE                   July 2026

   The "AKP" key type mandates the use of the "alg" parameter.  While
   this requirement is suitable for PQ digital signature algorithms,
   applying the same model to PQ KEMs would require distinguishing
   between keys used for Direct Key Agreement and those used for Key
   Agreement with Key Wrap.

   Note: This differs from the "OKP" usage model and requires further
   discussion within the WG.

   For ML-KEM algorithms, as specified in [FIPS203], there are two
   possible representations of a private key: a seed and a fully
   expanded private key derived from the seed.  This document specifies
   only the seed form.  The "priv" parameter MUST contain the 64-octet
   ML-KEM seed d || z, where d is the first 32 octets and z is the last
   32 octets.  The ML-KEM public key and expanded private key are
   derived from this seed using ML-KEM.KeyGen_internal(d, z), as
   specified in [FIPS203].  This document does not define a 32-octet
   private seed representation and does not support carrying the
   expanded private key in "priv".  This avoids implicit,
   implementation-specific key expansion.

9.  Security Considerations

   PQC KEMs used in the manner described in this document MUST
   explicitly be designed to be secure in the event that the public key
   is reused, such as achieving IND-CCA2 security.  ML-KEM has such
   security properties.

   ML-KEM key generation and encapsulation both rely on high-quality
   random input.  For key generation, the 64-octet seed d || z contains
   32 octets used to deterministically derive the key pair and 32 octets
   used as a rejection value.  For encapsulation, ML-KEM uses fresh
   random input to produce the ciphertext and shared secret.
   Implementations MUST use a cryptographically secure random number
   generator for these values.  Weak or repeated random input can make
   it substantially easier for an attacker to reproduce keys or
   ciphertexts and can undermine the security properties expected from
   ML-KEM.

   ML-KEM encapsulation and decapsulation output only the shared secret
   and ciphertext values described by this specification.
   Implementations MUST NOT use intermediate ML-KEM values directly as
   COSE keying material, KDF input, authentication input, or application
   data.  Implementations SHOULD avoid exposing intermediate values
   through APIs, logs, errors, or side channels.

10.  IANA Considerations

Reddy, et al.            Expires 7 January 2027                [Page 10]
Internet-Draft               PQ KEM for COSE                   July 2026

10.1.  COSE Algorithms Registrations

   IANA is requested to add the following entries to the "COSE
   Algorithms" registry [COSE-IANA]:

   *  Name: ML-KEM-512

   *  Value: TBD1

   *  Description: PQ-KEM that uses ML-KEM-512 PQ-KEM.

   *  Capabilities: [kty]

   *  Change Controller: IESG

   *  Reference: This document (TBD)

   *  Recommended: No

   *  Name: ML-KEM-768

   *  Value: TBD2

   *  Description: PQ-KEM that uses ML-KEM-768 PQ-KEM.

   *  Capabilities: [kty]

   *  Change Controller: IESG

   *  Reference: This document (TBD)

   *  Recommended: No

   *  Name: ML-KEM-1024

   *  Value: TBD3

   *  Description: PQ-KEM that uses ML-KEM-1024 PQ-KEM.

   *  Capabilities: [kty]

   *  Change Controller: IESG

   *  Reference: This document (TBD)

   *  Recommended: No

   *  Name: ML-KEM-512+A128KW

Reddy, et al.            Expires 7 January 2027                [Page 11]
Internet-Draft               PQ KEM for COSE                   July 2026

   *  Value: TBD4

   *  Description: PQ-KEM that uses ML-KEM-512 PQ-KEM and CEK wrapped
      with "A128KW".

   *  Capabilities: [kty]

   *  Change Controller: IESG

   *  Reference: This document (TBD)

   *  Recommended: No

   *  Name: ML-KEM-768+A192KW

   *  Value: TBD5

   *  Description: PQ-KEM that uses ML-KEM-768 and CEK wrapped with
      "A192KW".

   *  Capabilities: [kty]

   *  Change Controller: IESG

   *  Reference: This document (TBD)

   *  Recommended: No

   *  Name: ML-KEM-1024+A256KW

   *  Value: TBD6

   *  Description: PQ-KEM that uses ML-KEM-1024 and CEK wrapped with
      "A256KW".

   *  Capabilities: [kty]

   *  Change Controller: IESG

   *  Reference: This document (TBD)

   *  Recommended: No

10.2.  COSE Elliptic Curves Registrations

   IANA is requested to register the following values in the "COSE
   Elliptic Curves" registry [COSE-IANA-Curves].

Reddy, et al.            Expires 7 January 2027                [Page 12]
Internet-Draft               PQ KEM for COSE                   July 2026

10.2.1.  ML-KEM-512

           +===================+==============================+
           | Name              | ML-KEM-512                   |
           +===================+==============================+
           | Value             | TBD1                         |
           +-------------------+------------------------------+
           | Key Type          | AKP                          |
           +-------------------+------------------------------+
           | Description       | NIST Post-Quantum ML-KEM-512 |
           +-------------------+------------------------------+
           | Change Controller | IETF                         |
           +-------------------+------------------------------+
           | Reference         | This document                |
           +-------------------+------------------------------+
           | Recommended       | No                           |
           +-------------------+------------------------------+

                                 Table 1

10.2.2.  ML-KEM-768

           +===================+==============================+
           | Name              | ML-KEM-768                   |
           +===================+==============================+
           | Value             | TBD2                         |
           +-------------------+------------------------------+
           | Key Type          | AKP                          |
           +-------------------+------------------------------+
           | Description       | NIST Post-Quantum ML-KEM-768 |
           +-------------------+------------------------------+
           | Change Controller | IETF                         |
           +-------------------+------------------------------+
           | Reference         | This document                |
           +-------------------+------------------------------+
           | Recommended       | No                           |
           +-------------------+------------------------------+

                                 Table 2

10.2.3.  ML-KEM-1024

           +===================+===============================+
           | Name              | ML-KEM-1024                   |
           +===================+===============================+
           | Value             | TBD3                          |
           +-------------------+-------------------------------+
           | Key Type          | AKP                           |

Reddy, et al.            Expires 7 January 2027                [Page 13]
Internet-Draft               PQ KEM for COSE                   July 2026

           +-------------------+-------------------------------+
           | Description       | NIST Post-Quantum ML-KEM-1024 |
           +-------------------+-------------------------------+
           | Change Controller | IETF                          |
           +-------------------+-------------------------------+
           | Reference         | This document                 |
           +-------------------+-------------------------------+
           | Recommended       | No                            |
           +-------------------+-------------------------------+

                                  Table 3

Acknowledgments

   The authors thank AJITOMI Daisuke, Brian Campbell, Daniel Huigens,
   Filip Skokan, Ilari Liusvaara, Neil Madden, and Stepan Yakimovich for
   their contributions to this specification.

References

Normative References

   [COSE-IANA]
              IANA, "CBOR Object Signing and Encryption (COSE)", n.d.,
              <https://www.iana.org/assignments/cose>.

   [COSE-IANA-Curves]
              IANA, "COSE Elliptic Curves", n.d.,
              <https://www.iana.org/assignments/cose>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC8949]  Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", STD 94, RFC 8949,
              DOI 10.17487/RFC8949, December 2020,
              <https://www.rfc-editor.org/rfc/rfc8949>.

   [RFC9052]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Structures and Process", STD 96, RFC 9052,
              DOI 10.17487/RFC9052, August 2022,
              <https://www.rfc-editor.org/rfc/rfc9052>.

Reddy, et al.            Expires 7 January 2027                [Page 14]
Internet-Draft               PQ KEM for COSE                   July 2026

   [RFC9053]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053,
              August 2022, <https://www.rfc-editor.org/rfc/rfc9053>.

Informative References

   [FIPS203]  "FIPS-203: Module-Lattice-based Key-Encapsulation
              Mechanism Standard",
              <https://nvlpubs.nist.gov/nistpubs/FIPS/
              NIST.FIPS.203.pdf>.

   [FO]       "Secure Integration of Asymmetric and Symmetric Encryption
              Schemes", <https://link.springer.com/article/10.1007/
              s00145-011-9114-1>.

   [HHK]      "A Modular Analysis of the Fujisaki-Okamoto
              Transformation", <https://link.springer.com/
              chapter/10.1007/978-3-319-70500-2_12>.

   [I-D.ietf-cose-dilithium]
              Prorock, M. and O. Steele, "ML-DSA for JOSE and COSE",
              Work in Progress, Internet-Draft, draft-ietf-cose-
              dilithium-11, 15 November 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-cose-
              dilithium-11>.

   [I-D.ietf-cose-hpke]
              Tschofenig, H., Jones, M. B., Steele, O., Daisuke, A., and
              L. Lundblade, "Use of Hybrid Public-Key Encryption (HPKE)
              with CBOR Object Signing and Encryption (COSE)", Work in
              Progress, Internet-Draft, draft-ietf-cose-hpke-26, 4 July
              2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
              cose-hpke-26>.

   [I-D.ietf-pquip-pqc-engineers]
              Banerjee, A., Reddy.K, T., Schoinianakis, D., Hollebeek,
              T., and M. Ounsworth, "Post-Quantum Cryptography for
              Engineers", Work in Progress, Internet-Draft, draft-ietf-
              pquip-pqc-engineers-14, 25 August 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-pquip-
              pqc-engineers-14>.

   [I-D.ietf-pquip-pqt-hybrid-terminology]
              D, F., P, M., and B. Hale, "Terminology for Post-Quantum
              Traditional Hybrid Schemes", Work in Progress, Internet-
              Draft, draft-ietf-pquip-pqt-hybrid-terminology-06, 10
              January 2025, <https://datatracker.ietf.org/doc/html/
              draft-ietf-pquip-pqt-hybrid-terminology-06>.

Reddy, et al.            Expires 7 January 2027                [Page 15]
Internet-Draft               PQ KEM for COSE                   July 2026

   [I-D.ietf-tls-hybrid-design]
              Stebila, D., Fluhrer, S., and S. Gueron, "Hybrid key
              exchange in TLS 1.3", Work in Progress, Internet-Draft,
              draft-ietf-tls-hybrid-design-16, 7 September 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-tls-
              hybrid-design-16>.

   [NIST.SP.800-56Ar3]
              National Institute of Standards and Technology,
              "Recommendation for Pair-Wise Key-Establishment Schemes
              Using Discrete Logarithm Cryptography, NIST Special
              Publication 800-56A Revision 3", April 2018,
              <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
              NIST.SP.800-56Ar3.pdf>.

   [NISTFINAL]
              "NIST Releases First 3 Finalized Post-Quantum Encryption
              Standards", n.d., <https://www.nist.gov/news-
              events/news/2024/08/nist-releases-first-3-finalized-post-
              quantum-encryption-standards>.

   [PQCAPI]   "PQC - API notes",
              <https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-
              Cryptography/documents/example-files/api-notes.pdf>.

   [RFC6090]  McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
              Curve Cryptography Algorithms", RFC 6090,
              DOI 10.17487/RFC6090, February 2011,
              <https://www.rfc-editor.org/rfc/rfc6090>.

   [RFC9936]  Prat, J., Ounsworth, M., and D. Van Geest, "Use of ML-KEM
              in the Cryptographic Message Syntax (CMS)", RFC 9936,
              DOI 10.17487/RFC9936, March 2026,
              <https://www.rfc-editor.org/rfc/rfc9936>.

   [RSA]      "A Method for Obtaining Digital Signatures and Public-Key
              Cryptosystems+",
              <https://dl.acm.org/doi/pdf/10.1145/359340.359342>.

   [SP-800-108r1]
              "Recommendation for Key Derivation Using Pseudorandom
              Functions",
              <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
              NIST.SP.800-108r1-upd1.pdf>.

Authors' Addresses

Reddy, et al.            Expires 7 January 2027                [Page 16]
Internet-Draft               PQ KEM for COSE                   July 2026

   Tirumaleswar Reddy
   Nokia
   Bangalore
   Karnataka
   India
   Email: kondtir@gmail.com

   Aritra Banerjee
   Nokia
   London
   United Kingdom
   Email: aritra.banerjee@nokia.com

   Hannes Tschofenig
   University of the Bundeswehr Munich
   85577 Neubiberg
   Germany
   Email: hannes.tschofenig@gmx.net

Reddy, et al.            Expires 7 January 2027                [Page 17]