]> University of the Bundeswehr Munich

Neubiberg 85577 Germany hannes.tschofenig@gmx.net

Nokia

Bangalore Karnataka India kondtir@gmail.com

Security CBOR Object Signing and Encryption HQC COSE HPKE Post-Quantum Cryptography This document specifies Hamming Quasi-Cyclic (HQC)-based ciphersuites for use with COSE-HPKE. It defines fully specified COSE algorithms for HPKE Integrated Encryption and HPKE Key Encryption, using HQC or PQ/T hybrid HQC key encapsulation, SHAKE256 key derivation, and AES-256-GCM authenticated encryption. It specifies their AKP key representation and requests twelve COSE algorithm registrations. Message processing and context binding are inherited from COSE-HPKE. Discussion Venues Discussion of this document takes place on the CBOR Object Signing and Encryption Working Group mailing list (cose@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction COSE-HPKE embeds Hybrid Public Key Encryption in CBOR Object Signing and Encryption (COSE) . A COSE-HPKE algorithm identifier selects a complete HPKE ciphersuite and a COSE usage mode. This document adds ciphersuites using the KEMs of : HQC-1, HQC-3, and HQC-5, and the PQ/T hybrid KEMs HQC3-P256, HQC3-X25519, and HQC5-P384. Each KEM is combined with the SHAKE256 KDF of and AES-256-GCM. Separate COSE algorithms identify Integrated Encryption and Key Encryption. The document does not change the COSE-HPKE message formats, HPKE key schedule, or existing header parameters. It is also separate from direct PQ-KEM-for-COSE constructions using an external KDF and AES Key Wrap; their algorithm identifiers and key-use conventions do not apply here.

Conventions and Terminology 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. The notation of and applies. enc is the HPKE encapsulation output. The COSE ek header carries that output and not a recipient public key. ct is the HPKE AEAD ciphertext. A CEK is a content-encryption key used in the next lower COSE layer. "Integrated" and "Key Encryption" refer to the two COSE-HPKE usage modes. "Base" and "PSK" refer to HPKE authentication modes. These are independent choices; a COSE usage-mode identifier does not select between Base and PSK.

Ciphersuites The twelve ciphersuites are defined in . Each row selects exactly one COSE usage mode and one HPKE triple (kem_id, kdf_id, aead_id). Implementations MUST NOT substitute another KDF, AEAD, or KEM under the same COSE algorithm identifier. HQC COSE-HPKE algorithms

COSE name	COSE value	Mode	HPKE KEM
HPKE-HQC-1	TBD-COSE-HQC-1	Integrated	HQC-1
HPKE-HQC-3	TBD-COSE-HQC-3	Integrated	HQC-3
HPKE-HQC-5	TBD-COSE-HQC-5	Integrated	HQC-5
HPKE-HQC3-P256	TBD-COSE-HQC3-P256	Integrated	HQC3-P256
HPKE-HQC3-X25519	TBD-COSE-HQC3-X25519	Integrated	HQC3-X25519
HPKE-HQC5-P384	TBD-COSE-HQC5-P384	Integrated	HQC5-P384
HPKE-HQC-1-KE	TBD-COSE-HQC-1-KE	Key Encryption	HQC-1
HPKE-HQC-3-KE	TBD-COSE-HQC-3-KE	Key Encryption	HQC-3
HPKE-HQC-5-KE	TBD-COSE-HQC-5-KE	Key Encryption	HQC-5
HPKE-HQC3-P256-KE	TBD-COSE-HQC3-P256-KE	Key Encryption	HQC3-P256
HPKE-HQC3-X25519-KE	TBD-COSE-HQC3-X25519-KE	Key Encryption	HQC3-X25519
HPKE-HQC5-P384-KE	TBD-COSE-HQC5-P384-KE	Key Encryption	HQC5-P384

For every row, the HPKE KDF is SHAKE256 (kdf_id = 0x0011) as defined in , and the HPKE AEAD is AES-256-GCM (aead_id = 0x0002) as defined in . The kem_id is the corresponding allocation requested by . SHAKE256 is selected because HQC-KEM uses SHAKE256 internally, following the guidance in Section 7.1 of that the KDF match one used by the KEM where possible. A single KDF and AEAD limits the initial suite count while allowing all HQC KEMs.

Key Representation Keys MUST use the Algorithm Key Pair (AKP) key type of and the raw HPKE key mapping specified in Section 3.4 of . HQC COSE_Key parameters

Parameter	Label	Requirement
kty	1	Integer 7 (AKP)
alg	3	COSE algorithm value
pub	-1	HPKE SerializePublicKey output, bstr
priv	-2	HPKE SerializePrivateKey output, bstr, private keys only

The alg field MUST be present and MUST identify the ciphersuite for which the key is used. It MUST match the selected COSE-HPKE algorithm. This is a complete ciphersuite binding, not merely a KEM binding: HPKE-HQC-1 and HPKE-HQC-1-KE identify different key objects. The pub length for each KEM is given in . The priv value, when present, is the 32-octet seed serialization defined by . Expanded private keys MUST NOT be placed in priv. Public-key objects MUST NOT contain priv. No crv parameter is used. Public key and encapsulated key lengths

HPKE KEM	pub (octets)	ek (octets)
HQC-1	2241	4433
HQC-3	4514	8978
HQC-5	7237	14421
HQC3-P256	4579	9043
HQC3-X25519	4546	9010
HQC5-P384	7334	14518

Implementations MUST perform the deserialization and consistency checks specified by , including rejection of an imported seed and public-key pair that do not match. The parameter set MUST be determined from alg, not inferred from a byte-string length alone. If key_ops (label 4) is present, it MUST be [8] (derive bits) for a private key and [] for a public key, as required by Section 3.4 of . This is not a deriveKey permission and does not authorize use of the HQC key as a symmetric key. AKP thumbprints follow Section 6 of . They include the COSE algorithm value, so two ciphersuite bindings do not have the same thumbprint merely because their public-key bytes are identical.

Processing Requirements The processing of applies with the algorithms from and the key mapping in . Only the HPKE Single-Shot APIs are used. A new HPKE operation, with fresh encapsulation randomness, MUST be used for each independently encrypted message or recipient. Reusing a provisioned recipient public key is distinct from reusing encapsulation randomness or an HPKE encryption context. If the alg header is present, it MUST be protected and MUST match the selected suite. When it is omitted as permitted by , the suite MUST be unambiguously established by the application context and MUST still match the key's mandatory alg. A receiver MUST NOT try different suites until one decrypts successfully. The ek header MUST contain the raw HPKE enc output as a byte string in the unprotected header of the structure performing HPKE. Its expected length is given in . A missing header, incorrect type, or incorrect length MUST be rejected before invoking decapsulation. The checks of apply in addition to these COSE checks.

Integrated Encryption The algorithms without the -KE suffix MUST be used only with the Integrated Encryption processing of Section 3.2 of . This mode uses COSE_Encrypt0 and has one recipient. HPKE encrypts the raw content. The inputs and outputs are mapped as specified by the base document:

• info is empty unless the application supplies the same external value to both parties.
• aad is the encoded COSE Enc_structure with context Encrypt0, the protected-header byte string, and the application's external AAD.
• pt is the content to encrypt.
• enc is carried in the unprotected ek header.
• ct is the COSE_Encrypt0 ciphertext, or the detached ciphertext when that field is null.

HPKE manages the AEAD key and nonce internally.

Key Encryption The algorithms with the -KE suffix MUST be used only with the Key Encryption processing of Section 3.3 of . A COSE_Encrypt contains the content encrypted with an independently generated CEK. Each COSE_Recipient uses HPKE to encrypt that CEK for its recipient. The info input is the Recipient_structure of the base document, encoded according to the Core Deterministic Encoding Requirements in Section 4.2.1 of . Its four members bind the HPKE recipient context, the algorithm of the next lower COSE layer, the exact recipient protected-header bytes, and any agreed recipient extra information. The next_layer_alg value MUST match the algorithm of that lower layer. Deterministic encoding applies to the structure, not to re-encoding the protected-header bytes it contains. The HPKE aad input SHOULD be empty, with any additional data handled as specified in Section 3.3.4 of . The HPKE plaintext is the CEK. The encapsulation output is placed in the recipient's unprotected ek header, and the HPKE ciphertext is placed in that recipient's ciphertext field. The HPKE AEAD of these suites is always AES-256-GCM and encrypts the CEK. The selected outer algorithm determines the CEK length and its own nonce and usage requirements. There is no AES Key Wrap step and no COSE_KDF_Context in this processing. The receiver uses HPKE Open to recover the CEK, checks that its length is appropriate for the next layer, and processes that layer according to COSE. A failed HPKE Open or failed content authentication MUST NOT result in plaintext release. Each recipient receives an independent encapsulation and encrypted copy of the CEK.

Base and PSK Authentication Modes Both COSE usage modes support HPKE Base and PSK. Following , a protected psk_id selects PSK mode; its absence selects Base mode. The PSK is provided externally and MUST NOT be included in the COSE structure. Its provisioning, entropy, and matching requirements are those of . No additional COSE algorithm identifiers are required for PSK mode.

Failure Handling The explicit errors and implicit-rejection behavior of and apply. Implementations MUST NOT turn the internal HQC consistency check into a distinguishable COSE rejection signal. Implicit rejection continues through HPKE; authentication failure is handled through the normal Open path. Explicit parse or KEM failures stop the operation without releasing content or a CEK.

Security Considerations The security considerations of , , , , and apply. This document selects and encodes ciphersuites; it does not supply an independent proof of HQC or HPKE. The protected headers, Recipient_structure, and the distinction between HPKE info and aad MUST be handled exactly as specified by . Replacing that structure with the context from another COSE key-distribution mechanism can remove intended algorithm binding and produces a different construction. Applications MUST constrain algorithm selection by policy and MUST NOT silently fall back to another KEM, ciphersuite, or HQC revision after decryption failure. Selection of a high-category KEM does not remove limits imposed by a content algorithm, KDF, AEAD, PSK, or implementation. Multiple recipients do not form a hybrid KEM. If HQC and ML-KEM recipients independently protect the same CEK, either recipient's private key is sufficient to recover it. Confidentiality therefore depends on every enabled recovery path. Applications requiring security when one KEM fails can use the PQ/T hybrid ciphersuites in . Base mode does not authenticate the sender. A kid is a lookup hint, not a substitute for authenticated public-key distribution. Sender authentication can be provided by the PSK mode or suitable COSE-native mechanisms as described by the base document. Long-term recipient key compromise permits recovery of recorded messages. Fresh randomness is required for encapsulation and for CEK generation in Key Encryption mode. The 32-octet private seed is secret key material and implementations MUST protect it and all expanded keys and intermediate shared secrets against disclosure. Message-size limits need to account for the entire encoded COSE object, not just the plaintext. In Key Encryption mode, each HQC recipient adds its KEM ciphertext and an encrypted CEK. Implementations SHOULD bound parsing, reassembly, memory allocation, and decapsulation work. Detached content does not eliminate the per-recipient KEM ciphertext overhead.

IANA Considerations IANA is requested to add the following twelve entries to the "COSE Algorithms" registry . The entries are fully specified by . For every entry, the KDF is HPKE SHAKE256 (0x0011) and the AEAD is HPKE AES-256-GCM (0x0002).

Name	Value	Description
HPKE-HQC-1	TBD-COSE-HQC-1	Integrated Encryption: HQC-1, SHAKE256, AES-256-GCM
HPKE-HQC-3	TBD-COSE-HQC-3	Integrated Encryption: HQC-3, SHAKE256, AES-256-GCM
HPKE-HQC-5	TBD-COSE-HQC-5	Integrated Encryption: HQC-5, SHAKE256, AES-256-GCM
HPKE-HQC3-P256	TBD-COSE-HQC3-P256	Integrated Encryption: HQC3-P256, SHAKE256, AES-256-GCM
HPKE-HQC3-X25519	TBD-COSE-HQC3-X25519	Integrated Encryption: HQC3-X25519, SHAKE256, AES-256-GCM
HPKE-HQC5-P384	TBD-COSE-HQC5-P384	Integrated Encryption: HQC5-P384, SHAKE256, AES-256-GCM
HPKE-HQC-1-KE	TBD-COSE-HQC-1-KE	Key Encryption: HQC-1, SHAKE256, AES-256-GCM
HPKE-HQC-3-KE	TBD-COSE-HQC-3-KE	Key Encryption: HQC-3, SHAKE256, AES-256-GCM
HPKE-HQC-5-KE	TBD-COSE-HQC-5-KE	Key Encryption: HQC-5, SHAKE256, AES-256-GCM
HPKE-HQC3-P256-KE	TBD-COSE-HQC3-P256-KE	Key Encryption: HQC3-P256, SHAKE256, AES-256-GCM
HPKE-HQC3-X25519-KE	TBD-COSE-HQC3-X25519-KE	Key Encryption: HQC3-X25519, SHAKE256, AES-256-GCM
HPKE-HQC5-P384-KE	TBD-COSE-HQC5-P384-KE	Key Encryption: HQC5-P384, SHAKE256, AES-256-GCM

The following fields apply to every row:

• Capabilities: [kty]
• Change Controller: IESG
• Reference: this document, , , and
• Recommended: No

The corresponding HPKE KEM ID in each description is the identifier assigned to that KEM by . Those values MUST be resolved in before publication. The existing AKP key type and the ek and psk_id parameters defined by are reused.

References Normative References 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. 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. 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. 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. University of the Bundeswehr Munich Nokia This document specifies Hamming Quasi-Cyclic (HQC) key encapsulation mechanisms for use with Hybrid Public Key Encryption (HPKE). It defines the HPKE KEM interface, deterministic key-pair derivation, public and private key encodings, and input validation for three HQC parameter sets. It also defines three PQ/T hybrid KEMs that combine HQC with P-256, X25519, or P-384. It requests six HPKE KEM algorithm identifiers and reuses the existing HPKE key schedule, encryption operations, and export interface. 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. 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 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. IANA n.d.

Example These examples are pseudocode, not executable CBOR diagnostic notation or cryptographic test vectors. encode denotes CBOR encoding, bstr(name) denotes the byte string held in name, and symbolic algorithm and header identifiers stand for integer assignments. EK and PSK_ID denote the header labels assigned by . A future version of this specification will provide working examples.

AKP Public Key A corresponding private-key object includes -2: bstr(seed) with 32 octets and, if key_ops is present, replaces [] with [8]. A Key Encryption object uses its own matching -KE algorithm binding.

Integrated Encryption in Base Mode The tag is the optional COSE_Encrypt0 tag. enc has 4433 octets. The protected bytes shown are also used in Enc_structure, which is passed as HPKE AAD. ct contains the encrypted content and its 16-octet AES-GCM authentication tag. No external COSE IV is needed for the HPKE operation.

Key Encryption in Base Mode Here the independent CEK has 32 octets and content_iv has 12 octets. For the HQC-5 recipient, enc has 14421 octets. encrypted_cek has 48 octets: the encrypted 32-octet CEK followed by the 16-octet HPKE AES-GCM tag. The recipient's info is the deterministic encoding of: The protected-header byte string MUST be the same one transmitted in the recipient, not a separately re-encoded equivalent map. To use PSK mode, add PSK_ID: bstr(psk_id) to that protected map and supply the corresponding PSK externally. This also changes the bytes in info.