]> Nokia

Bangalore Karnataka India kondtir@gmail.com

Germany hannes.tschofenig@gmx.net

Security COSE PQC COSE JOSE Hybrid HPKE This document outlines the construction of a PQ/T Hybrid Key Encapsulation Mechanism (KEM) in Hybrid Public-Key Encryption (HPKE) for integration with JOSE and COSE. It specifies the utilization of both traditional and Post-Quantum Cryptography (PQC) algorithms, referred to as PQ/T Hybrid KEM, within the context of JOSE and COSE. About This Document 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 .

Introduction The migration to Post-Quantum Cryptography (PQC) is unique in the history of modern digital cryptography in that neither the traditional algorithms nor the post-quantum algorithms are fully trusted to protect data for the required data lifetimes. The traditional algorithms, such as RSA and elliptic curve, will fall to quantum cryptalanysis, while the post-quantum algorithms face uncertainty about the underlying mathematics, compliance issues, unknown vulnerabilities, hardware and software implementations that have not had sufficient maturing time to rule out classical cryptanalytic attacks and implementation bugs. During the transition from traditional to post-quantum algorithms, there is a desire or a requirement for protocols that use both algorithm types. Hybrid key exchange refers to using multiple key exchange algorithms simultaneously and combining the result with the goal of providing security even if all but one of the component algorithms is broken. It is motivated by transition to post-quantum cryptography. HPKE offers a variant of public-key encryption of arbitrary-sized plaintexts for a recipient public key. The specifications for the use of HPKE with JOSE and COSE are described in and , respectively. HPKE can be extended to support PQ/T Hybrid KEM as defined in . This specification defines PQ/T Hybrid KEM in HPKE for use with JOSE and COSE.

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 makes use of the terms defined in . 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 factorisation, finite field discrete logarithms, elliptic curve discrete logarithms, or related mathematical problems. In the context of JOSE, examples of traditional key exchange algorithms include Elliptic Curve Diffie-Hellman Ephemeral Static . In the context of COSE, examples of traditional key exchange algorithms include Ephemeral-Static (ES) DH and Static-Static (SS) DH . "Post-Quantum Algorithm": An asymmetric cryptographic algorithm that is believed to be secure against attacks using quantum computers as well as classical computers. Examples of PQC key exchange algorithms include ML-KEM. "Post-Quantum Traditional (PQ/T) Hybrid Scheme": A multi-algorithm scheme where at least one component algorithm is a post-quantum algorithm and at least one is a traditional algorithm. "PQ/T Hybrid Key Encapsulation Mechanism": A multi-algorithm KEM made up of two or more component KEM algorithms where at least one is a post-quantum algorithm and at least one is a traditional algorithm.

Construction 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 . In order of increasing security strength (and decreasing performance), these parameter sets are ML-KEM-512, ML-KEM-768, and ML-KEM-1024. X-Wing uses a multi-algorithm scheme, where one component algorithm is a post-quantum algorithm and another one is a traditional algorithm. X-Wing uses the final version of ML-KEM-768 and X25519. The Combiner function defined in Section 5.3 of combines the output of a post-quantum KEM and a traditional KEM to generate a single shared secret.

Ciphersuite Registration This specification registers a number of PQ/T Hybrid KEMs for use with HPKE. A ciphersuite is thereby a combination of several algorithm configurations:

• KEM algorithm (PQ KEM + Traditional Algorithm, for example, MLKEM768 + X25519 defined as "X-Wing" in )
• KDF algorithm
• AEAD algorithm

The "KEM", "KDF", and "AEAD" values are conceptually taken from the HPKE IANA registry . Hence, JOSE and COSE cannot use an algorithm combination that is not already available with HPKE. For readability the algorithm ciphersuites labels are built according to the following scheme: -- ]]> The HPKE PQ/T hybrid ciphersuites for JOSE and COSE are defined in . Note that the PQ/T Hybrid KEM in HPKE is not an authenticated KEM. The HPKE Base mode can only be supported with the PQ/T Hybrid KEM.

Security Considerations The security considerations in are to be taken into account. The shared secrets computed in the hybrid key exchange should be computed in a way that achieves the "hybrid" property: the resulting secret is secure as long as at least one of the component key exchange algorithms is unbroken. 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.

IANA Considerations

JOSE This document requests IANA to add new values to the "JSON Web Signature and Encryption Algorithms" registry.

JOSE Algorithms Registry

• Algorithm Name: HPKE-XWING-SHA256-AES256GCM
• Algorithm Description: Cipher suite for JOSE-HPKE in Base Mode that uses the XWING Hybrid KEM, the HKDF-SHA256 KDF, and the AES-256-GCM AEAD.
• Algorithm Usage Location(s): "alg"
• JOSE Implementation Requirements: Optional
• Change Controller: IANA
• Specification Document(s): [[TBD: This RFC]]
• Algorithm Analysis Documents(s): TODO
• Algorithm Name: HPKE-XWING-SHA256-ChaCha20Poly1305
• Algorithm Description: Cipher suite for JOSE-HPKE in Base Mode that uses the XWING Hybrid
  KEM, the HKDF-SHA256 KDF, and the ChaCha20Poly1305 AEAD.
• Algorithm Usage Location(s): "alg"
• JOSE Implementation Requirements: Optional
• Change Controller: IANA
• Specification Document(s): [[TBD: This RFC]]
• Algorithm Analysis Documents(s): TODO

JSON Web Key Elliptic Curves Registrations

• Curve name: X-Wing
• Curve description: X-Wing key pairs
• JOSE Implementation Requirements: TBD
• Change Controller: IESG
• Reference: This Document

COSE This document requests IANA to add new values to the 'COSE Algorithms' registry.

COSE Algorithms Registry

• Name: HPKE-Base-XWING-SHA256-AES256GCM
• Value: TBD1
• Description: Cipher suite for COSE-HPKE in Base Mode that uses the XWING Hybrid KEM, the
  HKDF-SHA256 KDF, and the AES-256-GCM AEAD.
• Capabilities: [kty]
• Change Controller: IANA
• Reference: [[TBD: This RFC]]
• Name: HPKE-Base-XWING-SHA256-ChaCha20Poly1305
• Value: TBD2
• Description: Cipher suite for COSE-HPKE in Base Mode that uses the XWING Hybrid
  KEM, the HKDF-SHA256 KDF, and the ChaCha20Poly1305 AEAD.
• Capabilities: [kty]
• Change Controller: IANA
• Reference: [[TBD: This RFC]]

COSE Elliptic Curves Registrations This document requests IANA to register the following value in the "COSE Elliptic Curves" registry.

• Name: X-Wing
• Value: TBD
• Key type: OKP
• Description: X-Wing
• Change Controller: IESG
• Reference: This document
• Recommended: TBD

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

References Normative References 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. Informative References IANA Nokia Nokia Transmute Self-Issued Consulting This specification defines Hybrid Public Key Encryption (HPKE) for use with JSON Object Signing and Encryption (JOSE). HPKE offers a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. HPKE works for any combination of an asymmetric key encapsulation mechanism (KEM), key derivation function (KDF), and authenticated encryption with additional data (AEAD) function. Authentication for HPKE in JOSE is provided by JOSE-native security mechanisms or by one of the authenticated variants of HPKE. This document defines the use of the HPKE with JOSE. University of Applied Sciences Bonn-Rhein-Sieg Transmute bibital 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 works for any combination of an asymmetric key encapsulation mechanism (KEM), key derivation function (KDF), and authenticated encryption with additional data (AEAD) function. Authentication for HPKE in COSE is provided by COSE-native security mechanisms or by one of the authenticated variants of HPKE. This document defines the use of the HPKE with COSE. SandboxAQ MPI-SP & Radboud University Cloudflare This memo defines X-Wing, a general-purpose post-quantum/traditional hybrid key encapsulation mechanism (PQ/T KEM) built on X25519 and ML- KEM-768. UK National Cyber Security Centre UK National Cyber Security Centre Naval Postgraduate School 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. This note describes the fundamental algorithms of Elliptic Curve Cryptography (ECC) as they were defined in some seminal references from 1994 and earlier. These descriptions may be useful for implementing the fundamental algorithms without using any of the specialized methods that were developed in following years. Only elliptic curves defined over fields of characteristic greater than three are in scope; these curves are those used in Suite B. This document is not an Internet Standards Track specification; it is published for informational purposes. This document defines how to use the Diffie-Hellman algorithms "X25519" and "X448" as well as the signature algorithms "Ed25519" and "Ed448" from the IRTF CFRG elliptic curves work in JSON Object Signing and Encryption (JOSE). 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.