]> Nokia

Bangalore Karnataka India kondtir@gmail.com

University of Applied Sciences Bonn-Rhein-Sieg

Germany hannes.tschofenig@gmx.net

Nokia

Munich Germany aritra.banerjee@nokia.com

Transmute

United States orie@transmute.industries

Self-Issued Consulting

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

Security JOSE HPKE JOSE PQC Hybrid 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. About This Document Status information for this document may be found at . Discussion of this document takes place on the jose Working Group mailing list (), which is archived at . Subscribe 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 specification enables JSON Web Encryption (JWE) to leverage HPKE, bringing support for KEMs and the possibility of Post Quantum or Hybrid KEMs to JWE.

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.

Conventions and Terminology This specification uses the following abbreviations and terms:

• Content Encryption Key (CEK), is defined in .
• Hybrid Public Key Encryption (HPKE) is 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 .

Overview This specification describes two modes of use for HPKE in JWE:

• HPKE JWE Integrated Encryption, where HPKE is used to encrypt the plaintext.
• HPKE JWE Key Encryption, where HPKE is used to encrypt a content encryption key (CEK) and the CEK is subsequently used to encrypt the plaintext.

When "alg" is a JOSE-HPKE algorithm:

• If "enc" is "dir", HPKE JWE Integrated Encryption is used.
• If "enc" is an AEAD algorithm, the recipient Key Managment mode is Key Encryption.

The HPKE KEM, KDF, and AEAD used depend on the JOSE-HPKE algorithm used. HPKE supports several modes, which are described in Table 1 of . In JWE, the use of specific HPKE modes such as "mode_base" or "mode_auth_psk" is determined by the presence of the header parameters "psk_id" and "auth_kid". JWE supports different serializations, including Compact JWE Serialization as described in Section 3.1 of , General JWE JSON Serialization as described in Section 3.2 of . Certain JWE features are only supported in specific serializations. For example Compact JWE Serialization does not support the following:

• additional authenticated data
• multiple recipients
• unprotected headers

HPKE JWE Key Encryption can be used with "aad" but only when not expressed with Compact JWE Serialization. Single recipient HPKE JWE Key Encryption with no "aad" can be expressed in Compact JWE Serialization, so long as the recipient and sender use the same HPKE Setup process as described in { Section 5 of RFC9180 }.

Auxiliary Authenticated Application Information HPKE has two places at which applications can specify auxiliary authenticated information as described in { Section 8.1 of RFC9180 }. HPKE algorithms are not required to process "apu" and "apv" as described in Section 4.6.1 of , despite appearing to be similar to key agreement algorithms (such as "ECDH-ES"). The "aad parameter" for Open() and Seal() MUST be used with both HPKE JWE Integrated Encryption and HPKE JWE Key Encryption. To avoid confusion between JWE AAD and HPKE AAD, this document uses the term "HPKE AEAD AAD" to refer the "aad parameter" for Open() and Seal().

Encapsulated Keys Encapsulated keys MUST be the base64url encoded encapsulated key as defined in Section 5.1.1 of . In HPKE JWE Integrated Encryption, JWE Encrypted Key is the encapsulated key. In HPKE JWE Key Encryption, each recipient JWE Encrypted Key is the encrypted content encryption key, and the encapsulated key (ek) is found in the recipient header.

Integrated Encryption In HPKE JWE Integrated Encryption:

• The protected header MUST contain an "alg" that starts with "HPKE".
• The protected header MUST contain an "enc" and it MUST be set to the value "dir". It updates Section 4.1.2 of to clarify that in case where HPKE JWE Integrated Encryption is used, setting "enc" set to "dir" is appropriate, as both the derivation of the CEK and the encryption of the plaintext are fully handled within the HPKE encryption.
• The protected header parameters "psk_id" and "auth_kid" MAY be present.
• The protected header parameter "ek" MUST NOT be present.
• The "encrypted_key" MUST be the base64url encoded encapsulated key as defined in Section 5.1.1 of .
• The "iv", "tag" and "aad" members MUST NOT be present.
• The "ciphertext" MUST be the base64url encoded ciphertext as defined in Section 5.2 of .
• The HPKE Setup info parameter MUST be set to an empty string.
• The HPKE AEAD AAD MUST be set to the "JWE Additional Authenticated Data encryption parameter", as defined in Step 14 of Section 5.1 of .

Note that compression is possible with integrated encryption, see Section 4.1.3 of . When decrypting, the checks in section 5.2, steps 1 through 5 MUST be performed. The JWE Encrypted Key in step 2 is the base64url encoded encapsulated key.

Compact Example A Compact JWE or JSON Web Token: After verification:

JSON Example A JSON Encoded JWE: After verification:

Key Encryption HPKE based recipients can be added alongside existing ECDH-ES+A128KW or RSA-OAEP-384 recipients because HPKE is only used to encrypt the content encryption key, and because the protected header used in content encryption is passed to HPKE as Additional Authenticated Data. The protected header encoding remains consistent with existing JWE formatting rules. In HPKE JWE Key Encryption:

• The JWE protected header MUST NOT contain the "alg" when recipients use different algorithms to secure the content encryption key.
• The JWE protected header SHOULD contain the "alg" when all recipients use the same HPKE algorithm to secure the content encryption key.
• The recipient unprotected header parameters "psk_id" and "auth_kid" MAY be present.
• The recipient unprotected header parameter "ek" MUST be present.
• The recipient unprotected header MUST contain a registered HPKE "alg" value.
• Recipient JWE Encrypted Key MUST be the ciphertext from HPKE Encryption.
• The "encrypted_key" MUST be the base64url encoded JWE Encrypted Key as described in Step 15 in Section 5.1 of . The recipient "encrypted_key" is as described in Section 7.2.1 of .
• The HPKE Setup info parameter MUST be set to an empty string.
• THE HPKE plaintext MUST be set to the CEK.

The processing of "enc", "iv", "tag", "aad", and "ciphertext" is already defined in . Implementations should follow the existing JWE specifications for handling these parameters, and no additional processing requirements are introduced by HPKE-based key encryption.

Multiple Recipients Example For example: After verification:

Mapping HPKE Keys to JWK for JOSE JWKs can be used to represent JOSE-HPKE private or public keys. For the algorithms defined in this document, the valid combinations of the JWE Algorithm, "kty", and "crv" are shown in .

JWK Types and Curves for JOSE-HPKE Ciphersuites

JWK Representation of a JOSE-HPKE Key with HPKE Ciphersuite An example is illustrated below for representing a JOSE-HPKE public/private keys.

Security Considerations This specification is based on HPKE and the security considerations of are therefore applicable also to this specification. HPKE assumes the sender is in possession of the public key of the recipient and HPKE JOSE makes the same assumptions. Hence, some form of public key distribution mechanism is assumed to exist but outside the scope of this document. HPKE in Base mode does not offer authentication as part of the HPKE KEM. In this case JOSE constructs like JWS and JSON Web Tokens (JWTs) can be used to add authentication. HPKE also offers modes that offer authentication. HPKE relies on a source of randomness to be available on the device. In Key Agreement with Key Wrapping mode, CEK has to be randomly generated and it MUST be ensured that the guidelines in for random number generations are followed.

Authentication using an Asymmetric Key Implementers are cautioned to note that the use of authenticated KEMs has different meaning when considering integrated encryption and key encryption. In integrated encryption the KEM operations secure the message plaintext, whereas with key encryption, the KEM operations secure the content encryption key. For this reason, the use of authenticated KEMs with key encryption is NOT RECOMMENDED, as it gives a false sense of security. See RFC9180 Section 5.1.3 for details authentication using asymmetric keys.

Key Management A single KEM key MUST NOT be used with multiple algorithms. Each key and its associated algorithm suite, comprising the KEM, KDF, and AEAD, should be managed independently. This separation prevents unintended interactions or vulnerabilities between suites, ensuring the integrity and security guarantees of each algorithm suite are preserved. Additionally, the same key MUST NOT be used for both key encryption and integrated encryption, as it may introduce security risks. It creates algorithm confusion, increases the potential for key leakage, cross-suite attacks, and improper handling of the key. A single recipient or sender key MUST NOT be used with both JOSE-HPKE and other algorithms as this might enable cross-protocol attacks.

Plaintext Compression Implementers are advised to review Section 3.6 of , which states: Compression of data SHOULD NOT be done before encryption, because such compressed data often reveals information about the plaintext.

Header Parameters Implementers are advised to review Section 3.10 of , which comments on application processing of JWE Protected Headers. Additionally, Unprotected Headers can contain similar information which an attacker could leverage to mount denial of service, forgery or injection attacks.

Ensure Cryptographic Keys Have Sufficient Entropy Implementers are advised to review Section 3.5 of , which provides comments on entropy requirements for keys. This guidance is relevant to both public and private keys used in both Key Encryption and Integrated Encryption. Additionally, this guidance is applicable to content encryption keys used in Key Encryption mode.

Validate Cryptographic Inputs Implementers are advised to review Section 3.4 of , which provides comments on the validation of cryptographic inputs. This guidance is relevant to both public and private keys used in both Key Encryption and Integrated Encryption, specifically focusing on the structure of the public and private keys. These inputs are crucial for the HPKE KEM operations.

Use Appropriate Algorithms Implementers are advised to review Section 3.2 of , which comments on the selection of appropriate algorithms. This is guidance is relevant to both Key Encryption and Integrated Encryption. When using Key Encryption, the strength of the content encryption algorithm should not be significantly different from the strengh of the Key Encryption algorithms used.

IANA Considerations This document adds entries to .

Ciphersuite Registration This specification registers a number of ciphersuites for use with HPKE. A ciphersuite is a group of algorithms, often sharing component algorithms such as hash functions, targeting a security level. A JOSE-HPKE algorithm, is composed of the following choices:

• HPKE Mode
• KEM Algorithm
• KDF Algorithm
• AEAD Algorithm

The "KEM", "KDF", and "AEAD" values are chosen from the HPKE IANA registry . The "HPKE Mode" is described in Table 1 of :

• "Base" refers to "mode_base" described in Section 5.1.1 of , which only enables encryption to the holder of a given KEM private key.
• "PSK" refers to "mode_psk", described in Section 5.1.2 of , which authenticates using a pre-shared key.
• "Auth" refers to "mode_auth", described in Section 5.1.3 of , which authenticates using an asymmetric key.
• "Auth_Psk" refers to "mode_auth_psk", described in Section 5.1.4 of , which authenticates using both a PSK and an asymmetric key.

Implementations detect the use of modes by inspecting header parameters.

JSON Web Signature and Encryption Algorithms The following entries are added to the "JSON Web Signature and Encryption Algorithms" registry:

HPKE-0

• Algorithm Name: HPKE-0
• Algorithm Description: Cipher suite for JOSE-HPKE in Base Mode that uses the DHKEM(P-256, HKDF-SHA256) KEM, the HKDF-SHA256 KDF and the AES-128-GCM AEAD.
• Algorithm Usage Location(s): "alg"
• JOSE Implementation Requirements: Optional
• Change Controller: IETF
• Specification Document(s): RFCXXXX
• Algorithm Analysis Documents(s): TODO

HPKE-1

• Algorithm Name: HPKE-1
• Algorithm Description: Cipher suite for JOSE-HPKE in Base Mode that uses the DHKEM(P-384, HKDF-SHA384) KEM, the HKDF-SHA384 KDF, and the AES-256-GCM AEAD.
• Algorithm Usage Location(s): "alg"
• JOSE Implementation Requirements: Optional
• Change Controller: IETF
• Specification Document(s): RFCXXXX
• Algorithm Analysis Documents(s): TODO

HPKE-2

• Algorithm Name: HPKE-2
• Algorithm Description: Cipher suite for JOSE-HPKE in Base Mode that uses the DHKEM(P-521, HKDF-SHA512) KEM, the HKDF-SHA512 KDF, and the AES-256-GCM AEAD.
• Algorithm Usage Location(s): "alg"
• JOSE Implementation Requirements: Optional
• Change Controller: IETF
• Specification Document(s): RFCXXXX
• Algorithm Analysis Documents(s): TODO

HPKE-3

• Algorithm Name: HPKE-3
• Algorithm Description: Cipher suite for JOSE-HPKE in Base Mode that uses the DHKEM(X25519, HKDF-SHA256) KEM, the HKDF-SHA256 KDF, and the AES-128-GCM AEAD.
• Algorithm Usage Location(s): "alg"
• JOSE Implementation Requirements: Optional
• Change Controller: IETF
• Specification Document(s): RFCXXXX
• Algorithm Analysis Documents(s): TODO

HPKE-4

• Algorithm Name: HPKE-4
• Algorithm Description: Cipher suite for JOSE-HPKE in Base Mode that uses the DHKEM(X25519, HKDF-SHA256) KEM, the HKDF-SHA256 KDF, and the ChaCha20Poly1305 AEAD.
• Algorithm Usage Location(s): "alg, enc"
• JOSE Implementation Requirements: Optional
• Change Controller: IETF
• Specification Document(s): RFCXXXX
• Algorithm Analysis Documents(s): TODO

HPKE-5

• Algorithm Name: HPKE-5
• Algorithm Description: Cipher suite for JOSE-HPKE in Base Mode that uses the DHKEM(X448, HKDF-SHA512) KEM, the HKDF-SHA512 KDF, and the AES-256-GCM AEAD.
• Algorithm Usage Location(s): "alg"
• JOSE Implementation Requirements: Optional
• Change Controller: IETF
• Specification Document(s): RFCXXXX
• Algorithm Analysis Documents(s): TODO

HPKE-6

• Algorithm Name: HPKE-6
• Algorithm Description: Cipher suite for JOSE-HPKE in Base Mode that uses the DHKEM(X448, HKDF-SHA512) KEM, the HKDF-SHA512 KDF, and the ChaCha20Poly1305 AEAD.
• Algorithm Usage Location(s): "alg"
• JOSE Implementation Requirements: Optional
• Change Controller: IETF
• Specification Document(s): RFCXXXX
• Algorithm Analysis Documents(s): TODO

JSON Web Signature and Encryption Header Parameters The following entries are added to the "JSON Web Key Parameters" registry:

ek

• Header Parameter Name: "ek"
• Header Parameter Description: An encapsulated key as defined in { Section 5.1.1 of RFC9180 }
• Header Parameter Usage Location(s): JWE
• Change Controller: IETF
• Specification Document(s): RFCXXXX

psk_id

• Header Parameter Name: "psk_id"
• Header Parameter Description: A key identifier (kid) for the pre-shared key as defined in { Section 5.1.2 of RFC9180 }
• Header Parameter Usage Location(s): JWE
• Change Controller: IETF
• Specification Document(s): RFCXXXX

auth_kid

• Header Parameter Name: "auth_kid"
• Header Parameter Description: A key identifier (kid) for the asymmetric key as defined in { Section 5.1.3 of RFC9180 }
• Header Parameter Usage Location(s): JWE
• Change Controller: IETF
• Specification Document(s): RFCXXXX

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. 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 three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. 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. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. JSON Web Encryption (JWE) represents encrypted content using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries defined by that specification. Related digital signature and Message Authentication Code (MAC) capabilities are described in the separate JSON Web Signature (JWS) specification. This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers. A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs. IANA n.d. 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. IANA 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.

Keys Used in Examples This private key and its implied public key are used the examples: This pre-shared key is used in the examples:

Acknowledgments This specification leverages text from . We would like to thank Matt Chanda, Ilari Liusvaara, Aaron Parecki, and Filip Skokan for their contributions to the specification.

Document History -05

• Removed incorrect text about HPKE algorithm names.
• Fixed #21: Comply with NIST SP 800-227 Recommendations for Key-Encapsulation Mechanisms.
• Fixed #19: Binding the Application Context.
• Fixed #18: Use of apu and apv in Recipeint context.
• Added new Section 7.1 (Authentication using an Asymmetric Key).
• Updated Section 7.2 (Key Management) to prevent cross-protocol attacks.
• Updated HPKE Setup info parameter to be empty.
• Added details on HPKE AEAD AAD, compression and decryption for HPKE Integrated Encryption.

-04

• Fixed #8: Use short algorithm identifiers, per the JOSE naming conventions.

-03

• Added new section 7.1 to discuss Key Management.
• HPKE Setup info parameter is updated to carry JOSE context-specific data for both modes.

-02

• Fixed #4: HPKE Integrated Encryption "enc: dir".
• Updated text on the use of HPKE Setup info parameter.
• Added Examples in Sections 5.1, 5.2 and 6.1.
• Use of registered HPKE "alg" value in the recipient unprotected header for Key Encryption.

-01

• Apply feedback from call for adoption.
• Provide examples of auth and psk modes for JSON and Compact Serializations
• Simplify description of HPKE modes
• Adjust IANA registration requests
• Remove HPKE Mode from named algorithms
• Fix AEAD named algorithms

-00

• Created initial working group version from draft-rha-jose-hpke-encrypt-07