]> Nokia

k.tirumaleswar_reddy@nokia.com

University of the Bundeswehr Munich

hannes.tschofenig@gmx.net

Okta

panva.ip@gmail.com

Security CBOR Object Signing and Encryption COSE HPKE post-quantum hybrid ML-KEM PQ PQ/T CRQC This document registers Post-Quantum (PQ) and Post-Quantum/Traditional (PQ/T) hybrid algorithm identifiers for use with CBOR Object Signing and Encryption (COSE), building on the Hybrid Public Key Encryption (HPKE) framework. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the cose Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction defines how to use Hybrid Public Key Encryption (HPKE) with COSE_Encrypt0 and COSE_Encrypt structures () using traditional Key Encapsulation Mechanisms (KEM) based on Elliptic-curve Diffie-Hellman (ECDH). This document extends the set of registered HPKE algorithms to include Post-Quantum (PQ) and Post-Quantum/Traditional (PQ/T) hybrid KEMs, as defined in . These algorithms provide protection against attacks by cryptographically relevant quantum computers. The term "PQ/T hybrid" is used here consistent with to denote a combination of post-quantum and traditional algorithms, and should not be confused with HPKE's use of "hybrid" to describe the combination of asymmetric and symmetric encryption.

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 when, and only when, they appear in all capitals, as shown here. This document uses the terms "Traditional Algorithm", "Post-Quantum Algorithm", "PQ/T Hybrid Scheme", and "PQ/T Hybrid KEM" as defined in . The term "pure post-quantum" is used in this document to refer to a single-algorithm scheme using only a post-quantum algorithm, with no traditional component.

Algorithm Identifiers This section defines the algorithm identifiers for PQ and PQ/T HPKE-based encryption in COSE. Each algorithm is defined by a combination of an HPKE KEM, a Key Derivation Function (KDF), and an Authenticated Encryption with Associated Data (AEAD) algorithm. All algorithms defined in this section follow the same operational model as those in , supporting both integrated encryption as defined in and key encryption as defined in . Test vectors for all algorithms defined in this section are provided in .

PQ/T Hybrid Integrated Encryption Algorithms The following table lists the algorithm identifiers for PQ/T hybrid integrated encryption, where HPKE directly encrypts the plaintext without a separate Content Encryption Key: PQ/T Hybrid Integrated Encryption Algorithms

Name	Value	HPKE KEM	HPKE KDF	HPKE AEAD
HPKE-8	TBD (Assumed: 54)	MLKEM768-P256 (0x0050)	SHAKE256 (0x0011)	AES-256-GCM (0x0002)
HPKE-9	TBD (Assumed: 56)	MLKEM768-X25519 (0x647a)	SHAKE256 (0x0011)	AES-256-GCM (0x0002)
HPKE-10	TBD (Assumed: 58)	MLKEM1024-P384 (0x0051)	SHAKE256 (0x0011)	AES-256-GCM (0x0002)

These algorithms combine ML-KEM with a traditional elliptic curve algorithm in a PQ/T hybrid KEM, with the goal that compromise of either the post-quantum or the traditional component alone does not undermine the security of the resulting encryption.

Pure PQ Integrated Encryption Algorithms The following table lists the algorithm identifiers for pure post-quantum integrated encryption: Pure PQ Integrated Encryption Algorithms

Name	Value	HPKE KEM	HPKE KDF	HPKE AEAD
HPKE-11	TBD (Assumed: 60)	ML-KEM-512 (0x0040)	SHAKE256 (0x0011)	AES-128-GCM (0x0001)
HPKE-12	TBD (Assumed: 62)	ML-KEM-768 (0x0041)	SHAKE256 (0x0011)	AES-256-GCM (0x0002)
HPKE-13	TBD (Assumed: 64)	ML-KEM-1024 (0x0042)	SHAKE256 (0x0011)	AES-256-GCM (0x0002)

These algorithms provide pure post-quantum security using ML-KEM without a traditional algorithm component.

PQ/T Hybrid Key Encryption Algorithms The following table lists the algorithm identifiers for PQ/T hybrid key encryption, where HPKE encrypts the Content Encryption Key: PQ/T Hybrid Key Encryption Algorithms

Name	Value	HPKE KEM	HPKE KDF	HPKE AEAD
HPKE-8-KE	TBD (Assumed: 55)	MLKEM768-P256 (0x0050)	SHAKE256 (0x0011)	AES-256-GCM (0x0002)
HPKE-9-KE	TBD (Assumed: 57)	MLKEM768-X25519 (0x647a)	SHAKE256 (0x0011)	AES-256-GCM (0x0002)
HPKE-10-KE	TBD (Assumed: 59)	MLKEM1024-P384 (0x0051)	SHAKE256 (0x0011)	AES-256-GCM (0x0002)

These are the key encryption counterparts of the PQ/T hybrid integrated encryption algorithms defined in .

Pure PQ Key Encryption Algorithms The following table lists the algorithm identifiers for pure post-quantum key encryption: Pure PQ Key Encryption Algorithms

Name	Value	HPKE KEM	HPKE KDF	HPKE AEAD
HPKE-11-KE	TBD (Assumed: 61)	ML-KEM-512 (0x0040)	SHAKE256 (0x0011)	AES-128-GCM (0x0001)
HPKE-12-KE	TBD (Assumed: 63)	ML-KEM-768 (0x0041)	SHAKE256 (0x0011)	AES-256-GCM (0x0002)
HPKE-13-KE	TBD (Assumed: 65)	ML-KEM-1024 (0x0042)	SHAKE256 (0x0011)	AES-256-GCM (0x0002)

These are the key encryption counterparts of the pure PQ integrated encryption algorithms defined in .

COSE_Key Representation Keys for the algorithms defined in this document use the "AKP" (Algorithm Key Pair) COSE key type defined in . The required "alg" (label 3) parameter identifies the HPKE ciphersuite as well as whether the key is used for Integrated Encryption or Key Encryption. The public key parameter (label -1) contains the SerializePublicKey() output for the corresponding KEM, and for private keys the private key parameter (label -2) contains the SerializePrivateKey() output, both as defined in . Both values are encoded as CBOR byte strings. Examples of COSE_Keys for each algorithm are provided in .

Security Considerations The security considerations of and apply to this document. provides general background on the threat posed by cryptographically relevant quantum computers (CRQCs), the properties of KEMs, and considerations for PQ/T hybrid schemes. This document registers ciphersuites based on ML-KEM-512. As noted in , given the relative novelty of ML-KEM, there is concern that new cryptanalysis might reduce the security level of ML-KEM-512. Use of ML-KEM-768 or ML-KEM-1024 acts as a hedge against such cryptanalysis at a modest performance penalty, and is RECOMMENDED where the additional overhead is acceptable. Unlike the companion JOSE algorithm registration document, this document retains ML-KEM-512-based ciphersuites for COSE. Discussion of this work identified COSE-specific deployment interest in these ciphersuites, including constrained environments and deployments that already support ML-KEM-512 in adjacent protocols and implementations. The ML-KEM-512 ciphersuites are therefore registered here to preserve that deployment option, while the stronger ML-KEM-768- and ML-KEM-1024-based ciphersuites remain the preferred choice when their additional overhead is acceptable. The PQ/T hybrid ciphersuites registered by this document are motivated by the PQ/T Hybrid Confidentiality property (, ): confidentiality is preserved as long as at least one of the component algorithms remains secure. The traditional component protects against unforeseen cryptanalysis of ML-KEM, while the post-quantum component protects against Harvest Now, Decrypt Later (HNDL) attacks () by a future CRQC. PQ/T hybrid ciphersuites are generally preferred for this reason during the transition to post-quantum cryptography. The pure PQ ciphersuites are registered to accommodate deployments with regulatory or compliance mandates that require the exclusive use of post-quantum algorithms, such as those governed by the Commercial National Security Algorithm Suite 2.0 , as well as deployments where the size or performance overhead of a traditional component is undesirable. When the Key Encryption algorithms defined in or are used in a COSE_Encrypt structure with multiple COSE_Recipient entries, all recipients MUST use a quantum-resistant Key Management algorithm. Including a recipient that uses an algorithm that is not quantum-resistant would allow an adversary performing an HNDL attack to recover the Content Encryption Key once a CRQC becomes available; see .

Security Strength Ciphersuites based on ML-KEM-512 target NIST post-quantum security level 1; those based on ML-KEM-768 target security level 3; and those based on ML-KEM-1024 target security level 5 (see ). In the PQ/T hybrid ciphersuites, the traditional component provides an additional classical security floor: P-256 and X25519 offer approximately 128-bit classical security, while P-384 offers approximately 192-bit classical security. The -KE variants share the same cryptographic properties as their integrated encryption counterparts. All ciphersuites use SHAKE256 as the KDF, aligning with the hash family used internally by ML-KEM. The AEAD is paired with the KEM security level: ML-KEM-512 ciphersuites use AES-128-GCM, while ML-KEM-768, ML-KEM-1024, and the PQ/T hybrid ciphersuites use AES-256-GCM. As discussed in , symmetric primitives are only modestly affected by quantum attacks and doubling key sizes is not strictly required; AES-256-GCM is nonetheless selected for the higher-strength ciphersuites to provide a comfortable margin consistent with security level 3 and 5 parameter sets and with contemporary guidance such as . AES-128-GCM is used with ML-KEM-512 since pairing a level-1 KEM with a level-5 AEAD would not improve the overall security level while increasing implementation and bandwidth cost. The widespread hardware acceleration and broad deployment of AES-GCM make it a reasonable choice for all ciphersuites defined in this document.

IANA Considerations

COSE Algorithms Registry This document requests registration of the following values in the IANA "COSE Algorithms" registry established by : Note: The HPKE algorithm numbering is intentionally aligned with the companion JOSE document so that a given HPKE identifier denotes the same HPKE KEM, KDF, and AEAD combination across JOSE and COSE.

HPKE-8

• Name: HPKE-8
• Value: TBD (Assumed: 54)
• Description: Integrated Encryption with HPKE using MLKEM768-P256 KEM, SHAKE256 KDF, and AES-256-GCM AEAD
• Capabilities: [kty]
• Change Controller: IETF
• Reference: of this document
• Recommended: Yes

HPKE-8-KE

• Name: HPKE-8-KE
• Value: TBD (Assumed: 55)
• Description: Key Encryption with HPKE using MLKEM768-P256 KEM, SHAKE256 KDF, and AES-256-GCM AEAD
• Capabilities: [kty]
• Change Controller: IETF
• Reference: of this document
• Recommended: Yes

HPKE-9

• Name: HPKE-9
• Value: TBD (Assumed: 56)
• Description: Integrated Encryption with HPKE using MLKEM768-X25519 KEM, SHAKE256 KDF, and AES-256-GCM AEAD
• Capabilities: [kty]
• Change Controller: IETF
• Reference: of this document
• Recommended: Yes

HPKE-9-KE

• Name: HPKE-9-KE
• Value: TBD (Assumed: 57)
• Description: Key Encryption with HPKE using MLKEM768-X25519 KEM, SHAKE256 KDF, and AES-256-GCM AEAD
• Capabilities: [kty]
• Change Controller: IETF
• Reference: of this document
• Recommended: Yes

HPKE-10

• Name: HPKE-10
• Value: TBD (Assumed: 58)
• Description: Integrated Encryption with HPKE using MLKEM1024-P384 KEM, SHAKE256 KDF, and AES-256-GCM AEAD
• Capabilities: [kty]
• Change Controller: IETF
• Reference: of this document
• Recommended: Yes

HPKE-10-KE

• Name: HPKE-10-KE
• Value: TBD (Assumed: 59)
• Description: Key Encryption with HPKE using MLKEM1024-P384 KEM, SHAKE256 KDF, and AES-256-GCM AEAD
• Capabilities: [kty]
• Change Controller: IETF
• Reference: of this document
• Recommended: Yes

HPKE-11

• Name: HPKE-11
• Value: TBD (Assumed: 60)
• Description: Integrated Encryption with HPKE using ML-KEM-512 KEM, SHAKE256 KDF, and AES-128-GCM AEAD
• Capabilities: [kty]
• Change Controller: IETF
• Reference: of this document
• Recommended: Yes

HPKE-11-KE

• Name: HPKE-11-KE
• Value: TBD (Assumed: 61)
• Description: Key Encryption with HPKE using ML-KEM-512 KEM, SHAKE256 KDF, and AES-128-GCM AEAD
• Capabilities: [kty]
• Change Controller: IETF
• Reference: of this document
• Recommended: Yes

HPKE-12

• Name: HPKE-12
• Value: TBD (Assumed: 62)
• Description: Integrated Encryption with HPKE using ML-KEM-768 KEM, SHAKE256 KDF, and AES-256-GCM AEAD
• Capabilities: [kty]
• Change Controller: IETF
• Reference: of this document
• Recommended: Yes

HPKE-12-KE

• Name: HPKE-12-KE
• Value: TBD (Assumed: 63)
• Description: Key Encryption with HPKE using ML-KEM-768 KEM, SHAKE256 KDF, and AES-256-GCM AEAD
• Capabilities: [kty]
• Change Controller: IETF
• Reference: of this document
• Recommended: Yes

HPKE-13

• Name: HPKE-13
• Value: TBD (Assumed: 64)
• Description: Integrated Encryption with HPKE using ML-KEM-1024 KEM, SHAKE256 KDF, and AES-256-GCM AEAD
• Capabilities: [kty]
• Change Controller: IETF
• Reference: of this document
• Recommended: Yes

HPKE-13-KE

• Name: HPKE-13-KE
• Value: TBD (Assumed: 65)
• Description: Key Encryption with HPKE using ML-KEM-1024 KEM, SHAKE256 KDF, and AES-256-GCM AEAD
• Capabilities: [kty]
• Change Controller: IETF
• Reference: of this document
• Recommended: Yes

References Normative References This document specifies JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for the Module-Lattice-Based Digital Signature Standard (ML-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in US NIST FIPS 204. University of the Bundeswehr Munich Self-Issued Consulting Tradeverifyd bibital LLC Security Theory LLC This specification defines hybrid public-key encryption (HPKE) for use with CBOR Object Signing and Encryption (COSE). HPKE offers a variant of public-key encryption of arbitrary-sized plaintexts for a recipient public key. HPKE is a general encryption framework utilizing an asymmetric key encapsulation mechanism (KEM), a key derivation function (KDF), and an Authenticated Encryption with Associated Data (AEAD) algorithm. This document defines the use of HPKE with COSE. Authentication for HPKE in COSE is provided by COSE-native security mechanisms or by the pre-shared key authenticated variant of HPKE. Cisco Selkie Cryptography Updating key exchange and public-key encryption protocols to resist attack by quantum computers is a high priority given the possibility of "harvest now, decrypt later" attacks. Hybrid Public Key Encryption (HPKE) is a widely-used public key encryption scheme based on combining a Key Encapsulation Mechanism (KEM), a Key Derivation Function (KDF), and an Authenticated Encryption with Associated Data (AEAD) scheme. In this document, we define KEM algorithms for HPKE based on both post-quantum KEMs and hybrid constructions of post- quantum KEMs with traditional KEMs, as well as a KDF based on SHA-3 that is suitable for use with these KEMs. When used with these algorithms, HPKE is resilient with respect to attacks by a quantum computer. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Inria Rosenpass This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes a variant that authenticates possession of a pre-shared key. HPKE works for any combination of an asymmetric Key Encapsulation Mechanism (KEM), key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. This document provides instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA-2. This document obsoletes RFC 9180. Informative References This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052). This document, along with RFC 9052, obsoletes RFC 8152. One aspect of the transition to post-quantum algorithms in cryptographic protocols is the development of hybrid schemes that incorporate both post-quantum and traditional asymmetric algorithms. This document defines terminology for such schemes. It is intended to be used as a reference and, hopefully, to ensure consistency and clarity across different protocols, standards, and organisations. The advent of a cryptographically relevant quantum computer (CRQC) would render state-of-the-art, traditional public key algorithms deployed today obsolete, as the mathematical assumptions underpinning their security would no longer hold. To address this, protocols and infrastructure must transition to post-quantum algorithms, which are designed to resist both traditional and quantum attacks. This document explains why engineers need to be aware of and understand post-quantum cryptography (PQC), and it details the impact of CRQCs on existing systems and the challenges involved in transitioning to post-quantum algorithms. Unlike previous cryptographic updates, this shift may require significant protocol redesign due to the unique properties of post-quantum algorithms. National Security Agency

Test Vectors This appendix provides test vectors for each algorithm defined in this document. For each algorithm, a private COSE_Key and an example encrypted COSE message (COSE_Encrypt0 for integrated encryption suites, or COSE_Encrypt with a single COSE_Recipient for key encryption suites) are provided, each shown in CBOR diagnostic notation and as hex-encoded CBOR. Long lines in the examples are folded using the single backslash strategy from . Before using a folded example as a test vector, remove the RFC 8792 header and unfold the lines according to that strategy. The complete unfolded vector set is available as examples/cose-vectors.json in the repository for this document.

HPKE-8

HPKE-8 COSE_Key (Diagnostic Notation)

HPKE-8 COSE_Key (Hex-Encoded CBOR)

HPKE-8 COSE_Encrypt0 (Diagnostic Notation)

HPKE-8 COSE_Encrypt0 (Hex-Encoded CBOR)

HPKE-8-KE

HPKE-8-KE COSE_Key (Diagnostic Notation)

HPKE-8-KE COSE_Key (Hex-Encoded CBOR)

HPKE-8-KE COSE_Encrypt (Diagnostic Notation)

HPKE-8-KE COSE_Encrypt (Hex-Encoded CBOR)

HPKE-9

HPKE-9 COSE_Key (Diagnostic Notation)

HPKE-9 COSE_Key (Hex-Encoded CBOR)

HPKE-9 COSE_Encrypt0 (Diagnostic Notation)

HPKE-9 COSE_Encrypt0 (Hex-Encoded CBOR)

HPKE-9-KE

HPKE-9-KE COSE_Key (Diagnostic Notation)

HPKE-9-KE COSE_Key (Hex-Encoded CBOR)

HPKE-9-KE COSE_Encrypt (Diagnostic Notation)

HPKE-9-KE COSE_Encrypt (Hex-Encoded CBOR)

HPKE-10

HPKE-10 COSE_Key (Diagnostic Notation)

HPKE-10 COSE_Key (Hex-Encoded CBOR)

HPKE-10 COSE_Encrypt0 (Diagnostic Notation)

HPKE-10 COSE_Encrypt0 (Hex-Encoded CBOR)

HPKE-10-KE

HPKE-10-KE COSE_Key (Diagnostic Notation)

HPKE-10-KE COSE_Key (Hex-Encoded CBOR)

HPKE-10-KE COSE_Encrypt (Diagnostic Notation)

HPKE-10-KE COSE_Encrypt (Hex-Encoded CBOR)

HPKE-11

HPKE-11 COSE_Key (Diagnostic Notation)

HPKE-11 COSE_Key (Hex-Encoded CBOR)

HPKE-11 COSE_Encrypt0 (Diagnostic Notation)

HPKE-11 COSE_Encrypt0 (Hex-Encoded CBOR)

HPKE-11-KE

HPKE-11-KE COSE_Key (Diagnostic Notation)

HPKE-11-KE COSE_Key (Hex-Encoded CBOR)

HPKE-11-KE COSE_Encrypt (Diagnostic Notation)

HPKE-11-KE COSE_Encrypt (Hex-Encoded CBOR)

HPKE-12

HPKE-12 COSE_Key (Diagnostic Notation)

HPKE-12 COSE_Key (Hex-Encoded CBOR)

HPKE-12 COSE_Encrypt0 (Diagnostic Notation)

HPKE-12 COSE_Encrypt0 (Hex-Encoded CBOR)

HPKE-12-KE

HPKE-12-KE COSE_Key (Diagnostic Notation)

HPKE-12-KE COSE_Key (Hex-Encoded CBOR)

HPKE-12-KE COSE_Encrypt (Diagnostic Notation)

HPKE-12-KE COSE_Encrypt (Hex-Encoded CBOR)

HPKE-13

HPKE-13 COSE_Key (Diagnostic Notation)

HPKE-13 COSE_Key (Hex-Encoded CBOR)

HPKE-13 COSE_Encrypt0 (Diagnostic Notation)

HPKE-13 COSE_Encrypt0 (Hex-Encoded CBOR)

HPKE-13-KE

HPKE-13-KE COSE_Key (Diagnostic Notation)

HPKE-13-KE COSE_Key (Hex-Encoded CBOR)

HPKE-13-KE COSE_Encrypt (Diagnostic Notation)

HPKE-13-KE COSE_Encrypt (Hex-Encoded CBOR)

Acknowledgments Thanks to Ilari Liusvaara and Orie Steele for the discussion and comments.

Document History draft-reddy-cose-hpke-pq-pqt-03

• Folded long test-vector lines using the RFC 8792 single backslash strategy

draft-reddy-cose-hpke-pq-pqt-02

• Added rationale for retaining ML-KEM-512-based ciphersuites for COSE
• Added a note that HPKE algorithm numbering is intentionally aligned with the companion JOSE registrations

draft-reddy-cose-hpke-pq-pqt-00

• Replaces draft-reddy-cose-jose-pqc-hybrid-hpke
• Removed ChaCha20Poly1305 AEAD ciphersuites
• Adapted source from draft-skokan-jose-hpke-pq-pqt-04 for COSE
• Added Filip Skokan as author