]> University of the Bundeswehr Munich

Neubiberg Bavaria 85577 Germany hannes.tschofenig@gmx.net

Tradeverifyd

United States orie@or13.io

bibital LLC

Japan dajiaji@gmail.com

Security Theory LLC

United States lgl@securitytheory.com

Self-Issued Consulting

United States michael_b_jones@hotmail.com https://self-issued.info/

Security COSE Internet-Draft 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. 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 Hybrid public-key encryption (HPKE) is a scheme that provides public key encryption of arbitrary-sized plaintexts given a recipient's public key. This document defines the use of HPKE with COSE (, ) with the single-shot APIs defined in . Multiple invocations of Open() / Seal() on the same context, as discussed in are not supported. Algorithm identifiers follow a ciphersuite scheme in which a single COSE algorithm ID maps to the three algorithm IDs required for HPKE: the Key Encapsulation Mechanism (KEM), the Key Derivation Function (KDF), and the Authenticated Encryption with Associated Data (AEAD) algorithm.

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. This specification uses the following abbreviations and terms:

• Content-encryption key (CEK), as described in .
• Hybrid Public Key Encryption (HPKE) as defined in .
• pkR is the public key of the recipient, as defined in .
• skR is the private key of the recipient, as defined in .
• Key Encapsulation Mechanism (KEM), see .
• Key Derivation Function (KDF), see .
• Authenticated Encryption with Associated Data (AEAD), see .
• Additional Authenticated Data (AAD), see .

HPKE for COSE

Overview This specification supports two modes of using HPKE in COSE, namely:

• HPKE Integrated Encryption mode, where HPKE is used to encrypt the plaintext. This mode can only be used with a single recipient. provides the details.
• HPKE Key Encryption mode, where HPKE is used to encrypt a content encryption key (CEK), which then encrypts the content. This mode supports multiple recipients. provides the details.

Distinct algorithm identifiers are defined and registered that are specific to each COSE HPKE mode so that they are fully specified, as required by . Algorithm identifiers MUST only be used in the COSE HPKE mode that is specified for them. In both cases, the new COSE header parameter "ek" MUST be present. It contains the encapsulated KEM shared secret. The value of this parameter MUST be the "enc" value output by the HPKE Seal() Single-Shot operation, as defined in . The "ek" header parameter MUST be encoded as a CBOR byte string. HPKE defines several authentication modes, as described in Table 1 of . This specification uses both 'mode_base' and 'mode_psk'. The mode is 'mode_psk' if the "psk_id" header parameter is present; otherwise, the mode defaults to 'mode_base'. 'mode_base' is described in , which only enables encryption to the holder of a given KEM private key. 'mode_psk' is described in , which authenticates using a pre-shared key. The "psk_id" header parameter, when present, MUST be a protected header parameter of the COSE structure of the corresponding HPKE operation. The PSK value itself is an external input to HPKE and MUST NOT be encoded in the COSE structure.

HPKE Integrated Encryption Mode This mode applies if the COSE_Encrypt0 structure uses a COSE-HPKE algorithm and has no recipient structure(s). Because COSE-HPKE supports header protection, if the "alg" parameter is present, it MUST be included in the protected header and MUST be a COSE-HPKE algorithm. Although the use of the "kid" parameter in COSE_Encrypt0 is discouraged by RFC 9052, this document RECOMMENDS the use of the "kid" parameter (or other parameters) to explicitly identify the static recipient public key used by the sender. If the COSE_Encrypt0 structure includes a "kid" parameter, the recipient MAY use it to select the corresponding private key. When encrypting, the inputs to the HPKE Seal Single-Shot operation are set as follows:

• kem_id: From the ciphersuite. See .
• pkR: The recipient public key, converted into an HPKE public key.
• kdf_id: From the ciphersuite. See .
• psk: If 'mode_psk' has been selected, the externally supplied pre-shared key. Otherwise, the empty string.
• psk_id: If 'mode_psk' has been selected, the value of the protected "psk_id" header parameter. Otherwise, the empty string.
• info: Defaults to the empty string; externally provided information MAY be used instead.
• aad: MUST contain the byte string for the authenticated data structure according to the steps defined in Section 5.3 of RFC 9052.

For the Integrated Encryption mode the context string will be "Encrypt0". Externally provided AAD information MAY be provided and MUST be passed into the Enc_structure via the external_aad field.

• aead_id: From the ciphersuite. See .
• pt: The raw message plaintext.

The outputs are used as follows:

• enc: MUST be placed raw into the "ek" (encapsulated key) parameter in the unprotected bucket.
• ct: MUST be used as layer ciphertext. If not using detached content, this is directly placed as ciphertext in COSE_Encrypt0 structure. Otherwise, it is transported separately and the ciphertext field is nil. See for a description of detached payloads.

If 'mode_psk' has been selected, then the "psk_id" parameter MUST be present. If 'mode_base' has been chosen, then the "psk_id" parameter MUST NOT be present. When decrypting, the inputs to the HPKE Open operation are set as follows:

• kem_id: From the ciphersuite. See .
• skR: The recipient private key, converted into an HPKE private key.
• kdf_id: From the ciphersuite. See .
• aead_id: From the ciphersuite. See .
• psk: If 'mode_psk' has been selected, the externally supplied pre-shared key. Otherwise, the empty string.
• psk_id: If 'mode_psk' has been selected, the value of the protected "psk_id" header parameter. Otherwise, the empty string.
• info: Defaults to the empty string; externally provided information MAY be used instead.
• aad: MUST contain the byte string for the authenticated data structure according to the steps defined in Section 5.3 of RFC 9052. For the Integrated Encryption mode the context string will be "Encrypt0". Externally provided AAD information MAY be provided and MUST be passed into the Enc_structure via the external_aad field.
• enc: The contents of the layer "ek" parameter.
• ct: The contents of the layer ciphertext.

The plaintext output is the raw message plaintext. The COSE_Encrypt0 MAY be tagged or untagged. An example is shown in .

HPKE Key Encryption Mode This mode is a Content Key Distribution Method like those specified in . It uses HPKE to protect the CEK. It is similar to the Key Agreement with Key Wrap method defined in . Internally, HPKE performs a key agreement to derive a shared secret and then uses that secret to wrap the CEK. A COSE_Encrypt structure is used with two logical layers:

• Layer 0 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 contains a COSE_Recipient with the parameters needed for HPKE to generate a shared secret used to encrypt the CEK. This layer conveys the encrypted CEK in the COSE_recipient structure using a COSE-HPKE algorithm.

This two-layer structure is used to encrypt content that can also be shared with multiple recipients at the expense of a single additional encryption operation. The content is encrypted once with the CEK, then the CEK is encrypted for each recipient. Layer 1 may also contain other COSE_Recipients using other content key distribution methods that also encrypt the CEK.

Recipient_structure When constructing a COSE_Recipient for COSE-HPKE, the Recipient_structure defined here is used in place of COSE_KDF_Context to aggregate the items that require protection. COSE-HPKE does not use the COSE_KDF_Context in any way. The Recipient_structure works akin to Sig_structure and Enc_structure defined in . It is constructed independently by the sender and the receiver only as an input to the cryptographic algorithms. It is not actually conveyed in the COSE message.

"next_layer_alg":

The algorithm ID of the COSE layer for which the COSE_recipient is encrypting a key. It is the algorithm that the key MUST be used with. This value MUST match the "alg" parameter in the next lower COSE layer.

"recipient_protected_header":

The protected header parameters from the COSE_recipient.

"recipient_extra_info":

Defaults to empty byte string. See .

The Recipient_structure MUST be serialized deterministically in accordance with the Core Deterministic Encoding Requirements defined in . This requirement applies only to the Recipient_structure itself — the array and its four members. It does not extend into the byte-string wrapped protected headers.

COSE-HPKE Recipient Construction This section gives the steps for constructing a COSE_Recipient using HPKE. Implementations may perform operations in this section in whichever order they choose, so long as the same bytes are produced as a result. First, the CEK is generated, usually using a high-quality random number generator. The CEK is used to encrypt the content. When encrypting the content at layer 0, the instructions in MUST be followed, including the calculation of the authenticated data structure. Any bulk external data that requires protection should be handled at layer 0 using external_aad. Next, assemble the protected headers. Note that they will be wrapped in a byte string. While the "alg" header parameter is not strictly required in the COSE_Recipient, if present, it must be the ciphersuite used to specify the HPKE algorithms. See . If the "alg" header parameter is present, it MUST be a protected header parameter. The protected header parameters MAY contain the "kid" header parameter to identify the static recipient public key that the sender used. Use of the "kid" parameter is RECOMMENDED to explicitly identify the static recipient public key used by the sender. Including it in the protected header parameters ensures that it is input into the key derivation function of HPKE. If 'mode_psk' has been selected, then the protected header MUST also contain the "psk_id" parameter. If 'mode_base' has been chosen, then the protected header MUST NOT contain the "psk_id" parameter. Next, construct a Recipeint_structure as described above. Next, the HPKE Seal Single-Shot operation is invoked with the following inputs:

• kem_id: From the ciphersuite. See .
• kdf_id: From the ciphersuite. See .
• aead_id: From the ciphersuite. See .
• pkR: The recipient public key, converted into HPKE public key.
• psk: If 'mode_psk' has been selected, the externally supplied pre-shared key. Otherwise, the empty string.
• psk_id: If 'mode_psk' has been selected, the value of the protected "psk_id" header parameter in the COSE_Recipient. Otherwise, the empty string.
• info: Deterministic encoding of the Recipient_structure. See .
• aad: SHOULD be empty. See .
• pt: The CEK.

The outputs go into the COSE_Recipient as follows:

• enc: MUST be placed into the "ek" (encapsulated key) header parameter in the unprotected bucket.
• ct: MUST be placed in the ciphertext field.

The COSE_recipient structure is computed for each recipient. Decrypting is largely the inverse of encrypting. When decrypting, the inputs to the HPKE Open operation are as follows:

• kdf_id: From the "alg" parameter ciphersuite. See .
• aead_id: From the "alg" parameter ciphersuite. See .
• kem_id: From the "alg" parameter ciphersuite. See .
• enc: From the "ek" parameter in the COSE_Recipient headers.
• skR: The recipient private key, converted into an HPKE private key.
• psk: If 'mode_psk' has been selected, the externally supplied pre-shared key. Otherwise, the empty string.
• psk_id: If 'mode_psk' has been selected, the value of the protected "psk_id" header parameter in the COSE_Recipient. Otherwise, the empty string.
• info: Deterministic encoding of the Recipient_structure. See .
• aad: SHOULD be empty. See .
• ct: The contents of the COSE_Recipient ciphertext field.

The plaintext output from the HPKE Open operation is the CEK. Any bulk external data that requires protection should be handled at layer 0 using external_aad. The COSE_recipient structure is computed for each recipient. When encrypting the content at layer 0, the instructions in MUST be followed, including the calculation of the authenticated data structure. An example is shown in .

Security Design Rationale COSE-HPKE does not use COSE_KDF_Context, which is defined in , for the following reasons:

• HPKE is a well-analyzed and widely reviewed construction that already incorporates the protections provided by COSE_KDF_Context.
• The HPKE design avoids many of the weaknesses present in earlier key agreement protocols that COSE_KDF_Context was designed to mitigate.
• Use of the COSE_KDF_Context would introduce unnecessary complexity; many of the fields typically go unused.
• It is difficult to know what to put in the COSE_KDF_Context fields.

The algorithm identifier for the bulk content encryption algorithm can be manipulated, since it is neither integrity-protected nor incorporated into the key derivation. In particular, the layer 0 algorithm identifier is not integrity protected by the COSE_Recipient and is therefore not cryptographically bound to the key agreement algorithm. This class of attack has been demonstrated against CMS; a corresponding mitigation is described in . The "next_layer_alg" member of the Recipient_structure mitigates this attack by explicitly binding the bulk content encryption algorithm identifier with the COSE_Recipient. The "next_layer_alg" member is explicitly defined to identify the algorithm for the immediately following COSE layer. Such explicit layering semantics were not provided for the AlgorithmID field in COSE_KDF_Context, where the intended interpretation was ambiguous.

Context Binding and Additional Information All header parameters in the protected bucket of the COSE_Recipient are incorporated into the HPKE Single-Shot Seal/Open info parameter via the Recipient_structure. As a result, these parameters are both integrity-protected and bound to the HPKE key schedule, since they influence the internal HPKE key setup. In most cases, additional header parameters carry supplementary data such as a "kid". If a use case requires binding the encryption context to public information, placing that information in the protected header parameters is a straightforward approach: the value will be transmitted to the recipient and automatically incorporated into the HPKE key schedule. For example, a new header parameter identifying the application-level protocol that uses COSE-HPKE could be defined. Its value would be authenticated and would also influence the HPKE key setup. Because all header parameters are transmitted in the clear, they cannot be used to bind information that must remain secret. The "recipient_extra_info" field in the Recipient_structure is also included in the HPKE Single-Shot Seal/Open info parameter, but unlike header parameters it is not transmitted. This makes it suitable for binding context information that is, for example, provided in other layers of the protocol stack or via out-of-band means. It is the responsibility of the specific use case to ensure that both sender and receiver possess this context information. There are minor size considerations. HPKE guarantees support for at least 64 bytes in the info parameter, and implementations are expected to support up to 16,384 bytes. This indirectly imposes a size limit on the COSE_Recipient protected header parameters and the "recipient_extra_info" field. In practice, this limit is unlikely to pose problems except in highly constrained environments or in use cases with unusually large header parameters. Protection and binding of auxiliary information can generally be achieved using protected header parameters together with the "recipient_extra_info" field, so use of the Single-Shot Seal/Open aad parameter is rarely necessary. However, it remains available for special cases and has no practical size limit.

Key Representation The COSE_Key with the existing key types can be used to represent KEM private or public keys. When using a COSE_Key for COSE-HPKE, the following checks are made:

• If the "kty" field is "AKP", then the public and private keys SHALL be the raw HPKE public and private keys (respectively) for the KEM used by the algorithm.
• Otherwise, the key MUST be suitable for the KEM used by the algorithm. In case the "kty" parameter is "EC2" or "OKP", this means the value of "crv" parameter is suitable. The valid combinations of KEM, "kty" and "crv" for the algorithms defined in this document are shown in .
• If the "key_ops" field is present, it MUST include only "derive bits" for the private key and MUST be empty for the public key.

Examples of the COSE_Key for COSE-HPKE are shown in .

Ciphersuite Registration A ciphersuite is a set of cryptographic algorithms selected to achieve a specific security level. For COSE-HPKE, a single COSE algorithm ID represents a ciphersuite that maps to the following HPKE algorithm identifiers:

• KEM algorithm
• KDF algorithm
• AEAD algorithm

Each COSE algorithm ID registered for COSE-HPKE MUST indicate the three HPKE algorithm IDs mapped by the ciphersuite. The HPKE mode is determined by the presence or absence of the "psk_id" parameter and is therefore not explicitly indicated in the ciphersuite. For a list of ciphersuite registrations, please see . The following table summarizes the relationship between the ciphersuites registered in this document and the values registered in the HPKE IANA registry . The following list maps the ciphersuite labels to their textual description.

• HPKE-0: Integrated Encryption with DHKEM(P-256, HKDF-SHA256) KEM, HKDF-SHA256 KDF, and AES-128-GCM AEAD.
• HPKE-1: Integrated Encryption with DHKEM(P-384, HKDF-SHA384) KEM, HKDF-SHA384 KDF, and AES-256-GCM AEAD.
• HPKE-2: Integrated Encryption with DHKEM(P-521, HKDF-SHA512) KEM, HKDF-SHA512 KDF, and AES-256-GCM AEAD.
• HPKE-3: Integrated Encryption with DHKEM(X25519, HKDF-SHA256) KEM, HKDF-SHA256 KDF, and AES-128-GCM AEAD.
• HPKE-4: Integrated Encryption with DHKEM(X25519, HKDF-SHA256) KEM, HKDF-SHA256 KDF, and ChaCha20Poly1305 AEAD.
• HPKE-5: Integrated Encryption with DHKEM(X448, HKDF-SHA512) KEM, HKDF-SHA512 KDF, and AES-256-GCM AEAD.
• HPKE-6: Integrated Encryption with DHKEM(X448, HKDF-SHA512) KEM, HKDF-SHA512 KDF, and ChaCha20Poly1305 AEAD.
• HPKE-7: Integrated Encryption with DHKEM(P-256, HKDF-SHA256) KEM, HKDF-SHA256 KDF, and AES-256-GCM AEAD.
• HPKE-0: Key Encryption with DHKEM(P-256, HKDF-SHA256) KEM, HKDF-SHA256 KDF, and AES-128-GCM AEAD.
• HPKE-1: Key Encryption with DHKEM(P-384, HKDF-SHA384) KEM, HKDF-SHA384 KDF, and AES-256-GCM AEAD.
• HPKE-2: Key Encryption with DHKEM(P-521, HKDF-SHA512) KEM, HKDF-SHA512 KDF, and AES-256-GCM AEAD.
• HPKE-3: Key Encryption with DHKEM(X25519, HKDF-SHA256) KEM, HKDF-SHA256 KDF, and AES-128-GCM AEAD.
• HPKE-4: Key Encryption with DHKEM(X25519, HKDF-SHA256) KEM, HKDF-SHA256 KDF, and ChaCha20Poly1305 AEAD.
• HPKE-5: Key Encryption with DHKEM(X448, HKDF-SHA512) KEM, HKDF-SHA512 KDF, and AES-256-GCM AEAD.
• HPKE-6: Key Encryption with DHKEM(X448, HKDF-SHA512) KEM, HKDF-SHA512 KDF, and ChaCha20Poly1305 AEAD.
• HPKE-7: Key Encryption with DHKEM(P-256, HKDF-SHA256) KEM, HKDF-SHA256 KDF, and AES-256-GCM AEAD.

As the list indicates, the ciphersuite labels have been abbreviated at least to some extent to strike a balance between readability and length. The ciphersuite list above is a minimal starting point. Additional ciphersuites can be registered into the already existing registry. For example, once post-quantum cryptographic algorithms have been standardized it might be beneficial to register ciphersuites for use with COSE-HPKE. Additionally, ciphersuites utilizing the compact encoding of the public keys, as defined in , may be standardized for use in constrained environments. As a guideline for ciphersuite submissions to the IANA COSE algorithm registry, the designated experts must only register combinations of (KEM, KDF, AEAD) triple that constitute valid combinations for use with HPKE, the KDF used should (if possible) match one internally used by the KEM, and components should not be mixed between global and national standards.

COSE_Keys for COSE-HPKE Ciphersuites The COSE-HPKE algorithm uniquely determines the KEM for which a COSE_Key is used. The following mapping table shows the valid combinations of the KEM used, COSE_Key type, and its curve/key subtype. This holds for COSE algorithms using either of the COSE HPKE modes (Integrated Encryption and Key Encryption).

COSE_Key Types and Curves for COSE-HPKE Ciphersuites

Examples This section provides a set of examples that show the HPKE Integrated Encryption Mode and the HPKE Key Encryption Mode, and illustrates the use of key representations for HPKE KEM.

COSE HPKE Integrated Encryption Mode This example assumes that a sender wants to communicate an encrypted payload to a single recipient, named "bob". An example of the HPKE Integrated Encryption Mode is shown in . Line breaks and comments have been inserted for better readability. This example uses the following:

• Suite: HPKE-0 (P-256 / HKDF-SHA256 / AES-128-GCM)
• Plaintext: "This is the content."
• External AAD: empty
• External Info: empty
• Recipient kid: "bob"

The ciphertext (hex) transmitted to "bob" is:

Hex-Encoding of COSE_Encrypt0

COSE_Encrypt0 pretty-printed:

COSE_Encrypt0 Example for HPKE

The following COSE Key was used in this example:

COSE Key

COSE HPKE Key Encryption Mode An example of key encryption using the COSE_Encrypt structure using HPKE is shown in below. Line breaks and comments have been inserted for better readability. This example uses the following input parameters:

• Content encryption algorithm: AES-128-GCM
• plaintext: "This is the content."
• kid:"bob"
• alg: HPKE-0-KE (assumed 46) - Key Encryption, DHKEM(P-256, HKDF-SHA256), KDF: HKDF-SHA256, AEAD: AES-128-GCM
• external aad and info are empty

The following COSE Key is used: As a pretty-printed version: As a result, the following COSE_Encrypt payload is produced: Pretty-printed, this hex-sequence has the following content:

Key Representation Examples of private and public KEM key representation are shown below.

Public Key for HPKE-0

Public Key Representation Example for HPKE-0

Private Key for HPKE-0

Private Key Representation Example for HPKE-0

KEM Public Key for HPKE-4

Public Key Representation Example for HPKE-4

Security Considerations This specification is based on HPKE and the security considerations of are therefore applicable also to this specification. Both HPKE and HPKE COSE assume that the sender possesses the recipient's public key. Therefore, some form of public key distribution mechanism is assumed to exist, but this is outside the scope of this document. HPKE relies on a source of randomness to be available on the device. Additionally, with the two layer structure the CEK is randomly generated and it MUST be ensured that the guidelines in for random number generation are followed. HPKE in Base mode does not offer authentication as part of the HPKE KEM. In this case COSE constructs like COSE_Sign, COSE_Sign1, COSE_Mac, or COSE_Mac0 can be used to add authentication. If COSE_Encrypt or COSE_Encrypt0 is used with a detached ciphertext then the subsequently applied integrity protection via COSE_Sign, COSE_Sign1, COSE_Mac, or COSE_Mac0 does not cover this detached ciphertext. Implementers MUST ensure that the detached ciphertext also experiences integrity protection. This is, for example, the case when an AEAD cipher is used to produce the detached ciphertext but may not be guaranteed by non-AEAD ciphers.

IANA Considerations This document requests IANA to add new values to the 'COSE Algorithms' and to the 'COSE Header Parameters' registries.

COSE Algorithms Registry

HPKE-0

• Name: HPKE-0
• Value: TBD1 (Assumed: 35)
• Description: COSE HPKE Integrated Encryption using DHKEM(P-256, HKDF-SHA256) KEM, HKDF-SHA256 KDF, and AES-128-GCM AEAD.
• Capabilities: [kty]
• Change Controller: IESG
• Reference: [[TBD: This RFC]]
• Recommended: Yes

HPKE-1

• Name: HPKE-1
• Value: TBD3 (Assumed: 37)
• Description: COSE HPKE Integrated Encryption using DHKEM(P-384, HKDF-SHA384) KEM, HKDF-SHA384 KDF, and AES-256-GCM AEAD.
• Capabilities: [kty]
• Change Controller: IESG
• Reference: [[TBD: This RFC]]
• Recommended: Yes

HPKE-2

• Name: HPKE-2
• Value: TBD5 (Assumed: 39)
• Description: COSE HPKE Integrated Encryption using DHKEM(P-521, HKDF-SHA512) KEM, HKDF-SHA512 KDF, and AES-256-GCM AEAD.
• Capabilities: [kty]
• Change Controller: IESG
• Reference: [[TBD: This RFC]]
• Recommended: Yes

HPKE-3

• Name: HPKE-3
• Value: TBD7 (Assumed: 41)
• Description: COSE HPKE Integrated Encryption using DHKEM(X25519, HKDF-SHA256) KEM, HKDF-SHA256 KDF, and AES-128-GCM AEAD.
• Capabilities: [kty]
• Change Controller: IESG
• Reference: [[TBD: This RFC]]
• Recommended: Yes

HPKE-4

• Name: HPKE-4
• Value: TBD8 (Assumed: 42)
• Description: COSE HPKE Integrated Encryption using DHKEM(X25519, HKDF-SHA256) KEM, HKDF-SHA256 KDF, and ChaCha20Poly1305 AEAD.
• Capabilities: [kty]
• Change Controller: IESG
• Reference: [[TBD: This RFC]]
• Recommended: Yes

HPKE-5

• Name: HPKE-5
• Value: TBD9 (Assumed: 43)
• Description: COSE HPKE Integrated Encryption using DHKEM(X448, HKDF-SHA512) KEM, HKDF-SHA512 KDF, and AES-256-GCM AEAD.
• Capabilities: [kty]
• Change Controller: IESG
• Reference: [[TBD: This RFC]]
• Recommended: Yes

HPKE-6

• Name: HPKE-6
• Value: TBD10 (Assumed: 44)
• Description: COSE HPKE Integrated Encryption using DHKEM(X448, HKDF-SHA512) KEM, HKDF-SHA512 KDF, and ChaCha20Poly1305 AEAD.
• Capabilities: [kty]
• Change Controller: IESG
• Reference: [[TBD: This RFC]]
• Recommended: Yes

HPKE-7

• Name: HPKE-7
• Value: TBD13 (Assumed: 45)
• Description: COSE HPKE Integrated Encryption using DHKEM(P-256, HKDF-SHA256) KEM, HKDF-SHA256 KDF, and AES-256-GCM AEAD.
• Capabilities: [kty]
• Change Controller: IESG
• Reference: [[TBD: This RFC]]
• Recommended: Yes

HPKE-0-KE

• Name: HPKE-0-KE
• Value: TBD14 (Assumed: 46)
• Description: COSE HPKE Key Encryption using DHKEM(P-256, HKDF-SHA256) KEM, HKDF-SHA256 KDF, and AES-128-GCM AEAD.
• Capabilities: [kty]
• Change Controller: IESG
• Reference: [[TBD: This RFC]]
• Recommended: Yes

HPKE-1-KE

• Name: HPKE-1-KE
• Value: TBD15 (Assumed: 47)
• Description: COSE HPKE Key Encryption using DHKEM(P-384, HKDF-SHA384) KEM, HKDF-SHA384 KDF, and AES-256-GCM AEAD.
• Capabilities: [kty]
• Change Controller: IESG
• Reference: [[TBD: This RFC]]
• Recommended: Yes

HPKE-2-KE

• Name: HPKE-2-KE
• Value: TBD16 (Assumed: 48)
• Description: COSE HPKE Key Encryption using DHKEM(P-521, HKDF-SHA512) KEM, HKDF-SHA512 KDF, and AES-256-GCM AEAD.
• Capabilities: [kty]
• Change Controller: IESG
• Reference: [[TBD: This RFC]]
• Recommended: Yes

HPKE-3-KE

• Name: HPKE-3-KE
• Value: TBD17 (Assumed: 49)
• Description: COSE HPKE Key Encryption using DHKEM(X25519, HKDF-SHA256) KEM, HKDF-SHA256 KDF, and AES-128-GCM AEAD.
• Capabilities: [kty]
• Change Controller: IESG
• Reference: [[TBD: This RFC]]
• Recommended: Yes

HPKE-4-KE

• Name: HPKE-4-KE
• Value: TBD18 (Assumed: 50)
• Description: COSE HPKE Key Encryption using DHKEM(X25519, HKDF-SHA256) KEM, HKDF-SHA256 KDF, and ChaCha20Poly1305 AEAD.
• Capabilities: [kty]
• Change Controller: IESG
• Reference: [[TBD: This RFC]]
• Recommended: Yes

HPKE-5-KE

• Name: HPKE-5-KE
• Value: TBD19 (Assumed: 51)
• Description: COSE HPKE Key Encryption using DHKEM(X448, HKDF-SHA512) KEM, HKDF-SHA512 KDF, and AES-256-GCM AEAD.
• Capabilities: [kty]
• Change Controller: IESG
• Reference: [[TBD: This RFC]]
• Recommended: Yes

HPKE-6-KE

• Name: HPKE-6-KE
• Value: TBD20 (Assumed: 52)
• Description: COSE HPKE Key Encryption using DHKEM(X448, HKDF-SHA512) KEM, HKDF-SHA512 KDF, and ChaCha20Poly1305 AEAD.
• Capabilities: [kty]
• Change Controller: IESG
• Reference: [[TBD: This RFC]]
• Recommended: Yes

HPKE-7-KE

• Name: HPKE-7-KE
• Value: TBD21 (Assumed: 53)
• Description: COSE HPKE Key Encryption using DHKEM(P-256, HKDF-SHA256) KEM, HKDF-SHA256 KDF, and AES-256-GCM AEAD.
• Capabilities: [kty]
• Change Controller: IESG
• Reference: [[TBD: This RFC]]
• Recommended: Yes

COSE Header Parameters

ek Header Parameter

• Name: ek
• Label: TBD11 (Assumed: -4)
• Value type: bstr
• Value Registry: N/A
• Description: HPKE encapsulated key
• Reference: [[TBD: This RFC]]

psk_id Header Parameter

• Name: psk_id
• Label: TBD12 (Assumed: -5)
• Value type: bstr
• Value Registry: N/A
• Description: A key identifier (kid) for the pre-shared key as defined in
• Usage: This header parameter MUST be a protected header parameter of the COSE_Encrypt0 or COSE_Recipient structure for the HPKE operation. It MUST NOT be present as an unprotected header parameter.
• Reference: [[TBD: This RFC]]

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. Cisco Inria Inria 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. We provide 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 SHA2. Informative References Randomness is a crucial ingredient for Transport Layer Security (TLS) and related security protocols. Weak or predictable "cryptographically secure" pseudorandom number generators (CSPRNGs) can be abused or exploited for malicious purposes. An initial entropy source that seeds a CSPRNG might be weak or broken as well, which can also lead to critical and systemic security problems. This document describes a way for security protocol implementations to augment their CSPRNGs using long-term private keys. This improves randomness from broken or otherwise subverted CSPRNGs. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. This specification refers to cryptographic algorithm identifiers that fully specify the cryptographic operations to be performed, including any curve, key derivation function (KDF), and hash functions, as being "fully specified". It refers to cryptographic algorithm identifiers that require additional information beyond the algorithm identifier to determine the cryptographic operations to be performed as being "polymorphic". This specification creates fully-specified algorithm identifiers for registered JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) polymorphic algorithm identifiers, enabling applications to use only fully-specified algorithm identifiers. It deprecates those polymorphic algorithm identifiers. This specification updates RFCs 7518, 8037, and 9053. It deprecates polymorphic algorithms defined by RFCs 8037 and 9053 and provides fully-specified replacements for them. It adds to the instructions to designated experts in RFCs 7518 and 9053. Hewlett-Packard Enterprise This document describes enhancements to the Hybrid Public Key Encryption standard published by CFRG. These include use of "compact representation" of relevant public keys, support for key-wrapping, and two ways to address the use of HPKE on lossy networks: a determinstic, nonce-less AEAD scheme, and use of a rolling sequence number with existing AEAD schemes. Vigil Security, LLC This document specifies the derivation of the content-encryption key or the content-authenticated-encryption key in the Cryptographic Message Syntax (CMS) using HMAC-based Extract-and-Expand Key Derivation Function (HKDF) with SHA-256. The use of this mechanism provides protection against where the attacker manipulates the content-encryption algorithm identifier or the content-authenticated- encryption algorithm identifier. IANA

Contributors We would like to thank the following individuals for their contributions to the design of embedding the HPKE output into the COSE structure following a long and lively mailing list discussion:

• Richard Barnes
• Ilari Liusvaara

Finally, we would like to thank Russ Housley and Brendan Moran for their contributions to the draft as co-authors of initial versions.

Acknowledgements We would like to thank John Mattsson, Mike Prorock, Michael Richardson, Thomas Fossati, and Göran Selander for their contributions to the specification.

Testvectors The testvectors use the following input:

• Plaintext: "hpke test payload"
• AAD: "external-aad"
• Info: "external-info"
• HPKE AAD: "external-hpke-aad"
• PSK (for the PSK testvectors only): h'0247fd33b913760fa1fa51e1892d9f307fbe65eb171e8132c2af18555a738b82'
• PSK ID (for the PSK testvectors only): h'456e6e796e20447572696e206172616e204d6f726961' (= "Ennyn Durin aran Moria")

AAD is the COSE Enc_structure.external_aad. It is used as AAD for the COSE AEAD in Encrypt0/Encrypt (Layer 0). HPKE AAD is the HPKE AAD for CEK wrap/unwrap in Key Encryption (Layer 1). It is only passed to the HPKE Seal/Open of the CEK.