]> Okta

panva.ip@gmail.com

Ping Identity

bcampbell@pingidentity.com

University of the Bundeswehr Munich

hannes.tschofenig@gmx.net

Nokia

k.tirumaleswar_reddy@nokia.com

Security Javascript Object Signing and Encryption JOSE HPKE post-quantum hybrid ML-KEM PQ PQ/T JWE CRQC This document registers Post-Quantum (PQ) and Post-Quantum/Traditional (PQ/T) hybrid algorithm identifiers for use with JSON Object Signing and Encryption (JOSE), 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 Javascript Object Signing and Encryption 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 JSON Web Encryption (JWE) 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 JOSE. 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

"alg" value	HPKE KEM	HPKE KDF	HPKE AEAD
HPKE-8	MLKEM768-P256 (0x0050)	SHAKE256 (0x0011)	AES-256-GCM (0x0002)
HPKE-9	MLKEM768-X25519 (0x647a)	SHAKE256 (0x0011)	AES-256-GCM (0x0002)
HPKE-10	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

"alg" value	HPKE KEM	HPKE KDF	HPKE AEAD
HPKE-12	ML-KEM-768 (0x0041)	SHAKE256 (0x0011)	AES-256-GCM (0x0002)
HPKE-13	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

"alg" value	HPKE KEM	HPKE KDF	HPKE AEAD
HPKE-8-KE	MLKEM768-P256 (0x0050)	SHAKE256 (0x0011)	AES-256-GCM (0x0002)
HPKE-9-KE	MLKEM768-X25519 (0x647a)	SHAKE256 (0x0011)	AES-256-GCM (0x0002)
HPKE-10-KE	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

"alg" value	HPKE KEM	HPKE KDF	HPKE AEAD
HPKE-12-KE	ML-KEM-768 (0x0041)	SHAKE256 (0x0011)	AES-256-GCM (0x0002)
HPKE-13-KE	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 .

JSON Web Key Representation Keys for the algorithms defined in this document use the "AKP" (Algorithm Key Pair) key type defined in . The required "alg" parameter identifies the HPKE ciphersuite as well as whether the key is used for Integrated Encryption or Key Encryption. The required "pub" parameter contains the SerializePublicKey() output for the corresponding KEM, and for private keys the "priv" parameter contains the SerializePrivateKey() output, both as defined in . Both values are base64url-encoded () without padding. The KEM-specific serialization functions are specified in for pure ML-KEM and for PQ/T hybrid KEMs. Examples of JWKs 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 does not register algorithms using 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. 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. 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. Among the ciphersuites registered by this document are constructions similar to a PQ/T hybrid mechanism recommended for TLS in . Detailed recommendations for post-quantum cryptography, including adjustments to the "JOSE Implementation Requirements" values for existing entries in the "JSON Web Signature and Encryption Algorithms" registry, will be addressed in future work. When the Key Encryption algorithms defined in or are used in a General JWE JSON Serialization with multiple recipients, 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-768 target NIST post-quantum security level 3; 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. They also use AES‑256‑GCM as the AEAD. 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 to provide a comfortable margin consistent with security level 5 parameter sets and with contemporary guidance such as . AES-256-GCM is used as the sole AEAD to minimize the number of ciphersuites and reduce implementation complexity; its widespread hardware acceleration and broad deployment make it a reasonable single choice for all ciphersuites defined in this document.

IANA Considerations

JSON Web Signature and Encryption Algorithms Registry This document requests registration of the following values in the IANA "JSON Web Signature and Encryption Algorithms" registry established by : Note: The Algorithm Name numbering has intentional gaps so that a given identifier always denotes the same HPKE KEM, KDF, and AEAD combination regardless of whether it is used in JOSE or COSE. The gaps correspond to algorithms registered only in COSE for COSE-specific needs that do not apply to JOSE.

HPKE-8

• Algorithm Name: HPKE-8
• Algorithm Description: Integrated Encryption with HPKE using MLKEM768-P256 KEM, SHAKE256 KDF, and AES-256-GCM AEAD
• Algorithm Usage Location(s): "alg"
• JOSE Implementation Requirements: Optional
• Change Controller: IETF
• Specification Document(s): of this document
• Algorithm Analysis Document(s):

HPKE-8-KE

• Algorithm Name: HPKE-8-KE
• Algorithm Description: Key Encryption with HPKE using MLKEM768-P256 KEM, SHAKE256 KDF, and AES-256-GCM AEAD
• Algorithm Usage Location(s): "alg"
• JOSE Implementation Requirements: Optional
• Change Controller: IETF
• Specification Document(s): of this document
• Algorithm Analysis Document(s):

HPKE-9

• Algorithm Name: HPKE-9
• Algorithm Description: Integrated Encryption with HPKE using MLKEM768-X25519 KEM, SHAKE256 KDF, and AES-256-GCM AEAD
• Algorithm Usage Location(s): "alg"
• JOSE Implementation Requirements: Optional
• Change Controller: IETF
• Specification Document(s): of this document
• Algorithm Analysis Document(s):

HPKE-9-KE

• Algorithm Name: HPKE-9-KE
• Algorithm Description: Key Encryption with HPKE using MLKEM768-X25519 KEM, SHAKE256 KDF, and AES-256-GCM AEAD
• Algorithm Usage Location(s): "alg"
• JOSE Implementation Requirements: Optional
• Change Controller: IETF
• Specification Document(s): of this document
• Algorithm Analysis Document(s):

HPKE-10

• Algorithm Name: HPKE-10
• Algorithm Description: Integrated Encryption with HPKE using MLKEM1024-P384 KEM, SHAKE256 KDF, and AES-256-GCM AEAD
• Algorithm Usage Location(s): "alg"
• JOSE Implementation Requirements: Optional
• Change Controller: IETF
• Specification Document(s): of this document
• Algorithm Analysis Document(s):

HPKE-10-KE

• Algorithm Name: HPKE-10-KE
• Algorithm Description: Key Encryption with HPKE using MLKEM1024-P384 KEM, SHAKE256 KDF, and AES-256-GCM AEAD
• Algorithm Usage Location(s): "alg"
• JOSE Implementation Requirements: Optional
• Change Controller: IETF
• Specification Document(s): of this document
• Algorithm Analysis Document(s):

HPKE-12

• Algorithm Name: HPKE-12
• Algorithm Description: Integrated Encryption with HPKE using ML-KEM-768 KEM, SHAKE256 KDF, and AES-256-GCM AEAD
• Algorithm Usage Location(s): "alg"
• JOSE Implementation Requirements: Optional
• Change Controller: IETF
• Specification Document(s): of this document
• Algorithm Analysis Document(s):

HPKE-12-KE

• Algorithm Name: HPKE-12-KE
• Algorithm Description: Key Encryption with HPKE using ML-KEM-768 KEM, SHAKE256 KDF, and AES-256-GCM AEAD
• Algorithm Usage Location(s): "alg"
• JOSE Implementation Requirements: Optional
• Change Controller: IETF
• Specification Document(s): of this document
• Algorithm Analysis Document(s):

HPKE-13

• Algorithm Name: HPKE-13
• Algorithm Description: Integrated Encryption with HPKE using ML-KEM-1024 KEM, SHAKE256 KDF, and AES-256-GCM AEAD
• Algorithm Usage Location(s): "alg"
• JOSE Implementation Requirements: Optional
• Change Controller: IETF
• Specification Document(s): of this document
• Algorithm Analysis Document(s):

HPKE-13-KE

• Algorithm Name: HPKE-13-KE
• Algorithm Description: Key Encryption with HPKE using ML-KEM-1024 KEM, SHAKE256 KDF, and AES-256-GCM AEAD
• Algorithm Usage Location(s): "alg"
• JOSE Implementation Requirements: Optional
• Change Controller: IETF
• Specification Document(s): of this document
• Algorithm Analysis Document(s):

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. Nokia University of the Bundeswehr Munich Nokia Tradeverifyd Self-Issued Consulting This specification defines how to use Hybrid Public Key Encryption (HPKE) with JSON Web Encryption (JWE). HPKE enables public key encryption of arbitrary-sized plaintexts to a recipient's public key, and provides security against adaptive chosen ciphertext attacks. This specification chooses a specific subset of the HPKE features to use with JWE. This specification updates RFC 7516 (JWE) to enable use of Integrated Encryption as a Key Management Mode. 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. This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] 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. This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers. 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. This document defines three hybrid key agreement mechanisms for TLS 1.3 -- X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 -- that combine the post-quantum ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism) with an ECDHE (Ephemeral Elliptic Curve Diffie-Hellman) exchange. National Security Agency

Test Vectors This appendix provides test vectors for each algorithm defined in this document. For each algorithm, a private JWK, a Flattened JWE JSON Serialization example with Additional Authenticated Data, and a JWE Compact Serialization example are provided. 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/jose-vectors.json in the repository for this document.

HPKE-8

HPKE-8 Private JWK

HPKE-8 Flattened JWE JSON Serialization

HPKE-8 JWE Compact Serialization

HPKE-8-KE

HPKE-8-KE Private JWK

HPKE-8-KE Flattened JWE JSON Serialization

HPKE-8-KE JWE Compact Serialization

HPKE-9

HPKE-9 Private JWK

HPKE-9 Flattened JWE JSON Serialization

HPKE-9 JWE Compact Serialization

HPKE-9-KE

HPKE-9-KE Private JWK

HPKE-9-KE Flattened JWE JSON Serialization

HPKE-9-KE JWE Compact Serialization

HPKE-10

HPKE-10 Private JWK

HPKE-10 Flattened JWE JSON Serialization

HPKE-10 JWE Compact Serialization

HPKE-10-KE

HPKE-10-KE Private JWK

HPKE-10-KE Flattened JWE JSON Serialization

HPKE-10-KE JWE Compact Serialization

HPKE-12

HPKE-12 Private JWK

HPKE-12 Flattened JWE JSON Serialization

HPKE-12 JWE Compact Serialization

HPKE-12-KE

HPKE-12-KE Private JWK

HPKE-12-KE Flattened JWE JSON Serialization

HPKE-12-KE JWE Compact Serialization

HPKE-13

HPKE-13 Private JWK

HPKE-13 Flattened JWE JSON Serialization

HPKE-13 JWE Compact Serialization

HPKE-13-KE

HPKE-13-KE Private JWK

HPKE-13-KE Flattened JWE JSON Serialization

HPKE-13-KE JWE Compact Serialization

Acknowledgments The authors thank Deb Cooley, Michael B. Jones, Ilari Liusvaara, Neil Madden, John Mattsson, Michael Parsons, Simo Sorce, and Orie Steele for their reviews and comments.

Document History draft-ietf-jose-hpke-pq-pqt-02

• Added direct references to the KEM-specific serialization functions in I-D.ietf-hpke-pq
• Removed the general preference for PQ/T hybrid ciphersuites
• Added TLS recommendation context from RFC 10024 and a statement on future JOSE recommendations
• Added acknowledgments

draft-ietf-jose-hpke-pq-pqt-01

• Updated references

draft-ietf-jose-hpke-pq-pqt-00

• Initial WG draft following adoption confirmation

draft-skokan-jose-hpke-pq-pqt-05

• Folded long test-vector lines using the RFC 8792 single backslash strategy and added a pointer to the unfolded vector set in the repository

draft-skokan-jose-hpke-pq-pqt-04

• Removed ChaCha20Poly1305 AEAD ciphersuites
• Renumbered algorithms with intentional gaps to align identifiers with COSE; added an explanatory note in IANA Considerations
• Added a Security Strength subsection and HNDL/multi-recipient guidance to Security Considerations
• Added rationale for selecting AES-256-GCM as the sole AEAD
• Refactored the JSON Web Key Representation section
• Added informative references to I-D.ietf-pquip-pqc-engineers, RFC 9794, and CNSA 2.0
• Adopted RFC 9794 terminology in Conventions and Definitions
• Added rationale for registering both PQ/T hybrid and pure PQ ciphersuites in Security Considerations
• Added Hannes Tschofenig and Tirumaleswar Reddy as authors

draft-skokan-jose-hpke-pq-pqt-03

• Clarified "hybrid" terminology disambiguation in the Introduction
• Added descriptive text to Key Encryption algorithm sections
• Expanded Security Considerations with ML-KEM-512 omission rationale

draft-skokan-jose-hpke-pq-pqt-02

• Added Test Vectors appendix

draft-skokan-jose-hpke-pq-pqt-01

• Added example JWK representations

draft-skokan-jose-hpke-pq-pqt-00

• Initial draft