]> Nokia

Bangalore Karnataka India kondtir@gmail.com

Nokia

London United Kingdom aritra.banerjee@nokia.com

University of the Bundeswehr Munich

Neubiberg Bavaria 85577 Germany hannes.tschofenig@gmx.net

Security COSE PQC COSE Hybrid This document describes conventions for using Post-Quantum Key Encapsulation Mechanisms (PQ-KEMs) with CBOR Object Signing and Encryption (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 . Source for this draft and an issue tracker can be found at .

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 . 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 . In order of increasing security strength (and decreasing performance), these parameter sets are ML-KEM-512, ML-KEM-768, and ML-KEM-1024.

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 . 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

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 . "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.

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 .

• 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 , 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.

Design Rationales Sections 8.5.4 and 8.5.5 of COSE 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 transform or its variant on the PQC KEM part to ensure that the overall scheme is IND-CCA2 secure, as mentioned in . 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.

KEM PQC Algorithms At time of writing, NIST have standardized three PQC algorithms, with more expected to be standardised in the future (). These algorithms are not necessarily drop-in replacements for traditional asymmetric cryptographic algorithms. For instance, RSA and ECC 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.

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 . 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 ). The public/private key sizes, ciphertext key size, and PQ security levels of ML-KEM are detailed in Section 12 of .

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.

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

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.

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':

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

KDF

Key Derivation The key derivation for COSE is performed using KMAC as defined in NIST SP 800-108r1-upd1 . 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 , 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 .
• 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.

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 , is used to convey the ciphertext ct output by the PQ-KEM encapsulation algorithm.

Direct Key Agreement The CEK will be generated using the process explained in . 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 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.

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 ). 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.

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. lists the COSE algorithm values for the PQ-KEM ciphersuites defined by this document.

COSE PQ-KEM Ciphersuites.

Use of AKP Key Type for PQC KEM Keys in COSE The "AKP" (Algorithm Key Pair) key type, defined in , 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. 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 , 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 . 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.

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.

IANA Considerations

COSE Algorithms Registrations IANA is requested to add the following entries to the "COSE Algorithms" registry :

• 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
• 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

COSE Elliptic Curves Registrations IANA is requested to register the following values in the "COSE Elliptic Curves" registry .

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

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

ML-KEM-1024

Name	ML-KEM-1024
Value	TBD3
Key Type	AKP
Description	NIST Post-Quantum ML-KEM-1024
Change Controller	IETF
Reference	This document
Recommended	No

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 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. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. 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. IANA n.d. IANA n.d. Informative References n.d. National Institute of Standards and Technology 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. Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is a quantum-resistant Key Encapsulation Mechanism (KEM). Three parameter sets for the ML-KEM algorithm are specified by the US National Institute of Standards and Technology (NIST) in FIPS 203. In order of increasing security strength (and decreasing performance), these parameter sets are ML-KEM-512, ML-KEM-768, and ML-KEM-1024. This document specifies the conventions for using ML-KEM with the Cryptographic Message Syntax (CMS) using the KEMRecipientInfo structure defined in "Using Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS)" (RFC 9629). University of Waterloo Cisco Systems University of Haifa and Meta Hybrid key exchange refers to using multiple key exchange algorithms simultaneously and combining the result with the goal of providing security even if a way is found to defeat the encryption for all but one of the component algorithms. It is motivated by transition to post-quantum cryptography. This document provides a construction for hybrid key exchange in the Transport Layer Security (TLS) protocol version 1.3. 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. Nokia Nokia Nokia DigiCert Entrust Limited 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), detailing 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. 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. Tradeverifyd Tradeverifyd This document specifies JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for Module- Lattice-Based Digital Signature Standard (ML-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in US NIST FIPS 204.

Document History [[ to be removed by the RFC Editor before publication as an RFC ]] -00

• Initial COSE working group draft, based on draft-ietf-jose-pqc-kem-06.