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

Tradeverifyd

United States orie@or13.io

Self-Issued Consulting

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

Security JOSE HPKE JOSE JWE 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 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 JOSE. The specification chooses a specific subset of the HPKE features to use with JOSE. About This Document The latest revision of this draft can be found at . 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 . 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 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 defines 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 "int", HPKE JWE Integrated Encryption is used.
• If "enc" is an AEAD algorithm, the recipient Key Management 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 JOSE-HPKE, only "mode_base" and "mode_psk" are supported. When "psk_id" JOSE Header parameter is present the mode is "mode_psk", otherwise the mode is "mode_base". JWE supports different serializations, including Compact JWE Serialization as described in , General JWE JSON Serialization as described in . 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 . This specification updates the "enc" definition in by allowing the "enc" value "int" when the "alg" value is a JOSE-HPKE algorithm. When "alg" is not a JOSE-HPKE algorithm and the "enc" value is "int", the input MUST be rejected.

Auxiliary Authenticated Application Information The HPKE "aad parameter" for Open() and Seal() specified in is used with both HPKE JWE Integrated Encryption and HPKE JWE Key Encryption. Its value is the Additional Authenticated Data encryption parameter value computed in Step 14 of (Message Encryption). Despite similarities to ECDH-ES, this specification does not use the apu and apv header parameters, which are described in .

Encapsulated Keys HPKE encapsulated key is defined in . In HPKE JWE Integrated Encryption, the JWE Encrypted Key of the sole recipient is the HPKE encapsulated key. In HPKE JWE Key Encryption, each recipient JWE Encrypted Key is the encrypted content encryption key, and the value of JOSE Header parameter "ek" is base64url-encoded HPKE encapsulated key.

Integrated Encryption In HPKE JWE Integrated Encryption:

• The protected header MUST contain an "alg" that is JOSE-HPKE algorithm.
• The protected header MUST contain an "enc" with value "int". This is an explicit exception to requirement in that "enc" must be an AEAD algorithm. This is appropriate, as HPKE will perform plaintext encryption.
• The protected header parameters "psk_id" MAY be present.
• The protected header parameter "ek" MUST NOT be present.
• There MUST be exactly one recipient.
• The JWE Encrypted Key MUST be encapsulated key, as defined in .
• The JWE Initialization Vector and JWE Authentication Tag MUST be the empty octet sequence.
• The JWE AAD MAY be present when using the JWE JSON Serialization.
• The JWE Ciphertext is the ciphertext defined in .
• The HPKE info parameter defaults to the empty string; mutually known private information MAY be used instead. The concept of mutually known private information is defined in as an input to the key derivation function.
• The HPKE aad parameter MUST be set to the "Additional Authenticated Data encryption parameter", as specified in Step 14 of .
• Then follow Steps 11-19 of (Message Encryption).

When decrypting, the checks in , Steps 1 through 5 MUST be performed. The JWE Encrypted Key in Step 2 is the base64url-encoded encapsulated key.

Compact Example Below is an example of a Compact JWE using HPKE integrated encryption: The keys used for this example are in .

Key Encryption When using the JWE JSON Serialization, recipients using JOSE-HPKE can be added alongside other recipients (e.g., those using ECDH-ES+A128KW or RSA-OAEP-256), since HPKE is used to encrypt the Content Encryption Key, which is then processed as specified in JWE. The encoding of the protected header remains consistent with existing JWE rules. In HPKE JWE Key Encryption:

• The Key Management Mode is Key Encryption.
• When all recipients use the same HPKE algorithm to secure the Content Encryption Key, the JWE Protected Header SHOULD contain "alg". Otherwise, the JWE Protected Header (and JWE Shared Unprotected Header) MUST NOT contain "alg".
• JOSE Header parameter "alg" MUST be a JOSE-HPKE algorithm.
• JOSE Header parameter "psk_id" MAY be present.
• JOSE Header parameter "ek" MUST be present and contain the base64url-encoded HPKE encapsulated key.
• Recipient JWE Encrypted Key MUST be the ciphertext from HPKE Encryption.
• The HPKE info parameter contains the encoding of the Recipient_structure, which is described in .
• The HPKE AAD parameter defaults to the empty string; externally provided information MAY be used instead.
• THE HPKE plaintext MUST be set to the CEK.

The processing of "enc", "iv", "tag", "aad", and "ciphertext" is as already defined in . Implementations process these parameters as defined in ; no additional processing requirements are introduced by HPKE-based key encryption.

Recipient_structure The Recipient_structure is a JSON object with the following members:

• context (string): This member MUST include the constant string value "JOSE HPKE Recipient".
• next_layer_alg (string): Identifies the algorithm with which the HPKE-encrypted key MUST be used. Its value MUST match the "enc" (encryption algorithm) header parameter in the JWE protected header. This field is included for alignment with the COSE HPKE specification. Currently, there are no known attacks that allow a downgrade attack of the content encryption algorithm.
• recipient_protected_header (object): This member contains the base64url-encoded JWE Per-Recipient Unprotected Header (see JWE JSON Serialization in of the recipients member. To serialize this header member the procedure from Section 3.3 of RFC 7638 MUST be used. Unlike with RFC 7638, all members from this member are included except for the "ek" member. The inclusion of this data in the Recipient_structure allows context information to be included in the key derivation.
• recipient_extra_info (string): Contains additional context information that the application includes in the key derivation via the HPKE info parameter. Mutually known private information, which is defined in , MAY be used in this input parameter. If no additional context is provided, this value MUST be the empty string "".

Deterministic Serialization for HPKE info JSON texts that are semantically identical can serialize differently (e.g., member order, whitespace), which would lead to divergent info values and failed key agreement. To produce the HPKE info byte string from a Recipient_structure, both sides MUST produce the deterministic JSON representation using the JSON Web Key (JWK) Thumbprint serialization rules :

1. Construct the Recipient_structure JSON object exactly as defined .
2. Prepare the JSON structure based on Section 3.3 of RFC 7638.
3. Use the resulting JSON structure, base64url-encode it and use the octets as the HPKE info value.

Example The example below shows a pretty-printed JSON object with an empty recipient_extra_info member. The serialized JSON leads to: The base64url-encoded JSON structure above is used as the HPKE info bytes.

JSON Example Below is an example of a JWE using the JSON Serialization and HPKE key encryption: The keys used for this example are in .

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

When the "kty" field is "AKP" (Algorithm Key Pair ) and "alg" is a JOSE-HPKE algorithm, the public and private keys MUST be raw HPKE public and private keys (respectively) for the KEM used by HPKE.

JWK Representation of a JOSE-HPKE Key with HPKE Ciphersuite The example below is a JWK representation of a JOSE-HPKE public and private key: It uses the "key_ops" value of "encrypt", which is appropriate when using integrated encryption.

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. HPKE relies on a source of randomness being available on the device. In Key Agreement with Key Wrapping mode, the CEK has to be randomly generated. The guidance on randomness in applies.

Key Management A single KEM key should 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 algorithms, ensuring the integrity and security guarantees of each algorithm are preserved. Additionally, the same key should 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.

Static Asymmetric Authentication in HPKE Authenticated KEMs based on static asymmetric key authentication are not supported in JOSE HPKE for the following reasons:

• The security implications vary depending on whether they are applied to Key Encryption or Integrated Encryption. When used for Key Encryption, authenticated KEMs offer little meaningful security benefit and may give a false impression of data origin authentication.
• Authenticated KEMs are susceptible to Key-Compromise Impersonation (KCI) attacks. If the sender's static private key is compromised, an attacker can generate ciphertexts that the recipient will accept as authentic, compromising message integrity.

Review JWT Best Current Practices The guidance in about encryption is also pertinent to this specification.

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 makes choices for the following HPKE parameters:

• KEM Algorithm
• KDF Algorithm
• AEAD Algorithm

The "KEM", "KDF", and "AEAD" values are chosen from the IANA HPKE registry . All JOSE-HPKE algorithm identifiers registered by this specification begin with the string "HPKE-". Future JOSE-HPKE ciphersuite names registered MUST also follow this convention.

IANA Considerations

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

HPKE-0

• Algorithm Name: HPKE-0
• Algorithm Description: Cipher suite for JOSE-HPKE using 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): of this specification
• Algorithm Analysis Documents(s):

HPKE-1

• Algorithm Name: HPKE-1
• Algorithm Description: Cipher suite for JOSE-HPKE using 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): of this specification
• Algorithm Analysis Documents(s):

HPKE-2

• Algorithm Name: HPKE-2
• Algorithm Description: Cipher suite for JOSE-HPKE using 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): of this specification
• Algorithm Analysis Documents(s):

HPKE-3

• Algorithm Name: HPKE-3
• Algorithm Description: Cipher suite for JOSE-HPKE using 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): of this specification
• Algorithm Analysis Documents(s):

HPKE-4

• Algorithm Name: HPKE-4
• Algorithm Description: Cipher suite for JOSE-HPKE using the DHKEM(X25519, HKDF-SHA256) KEM, the HKDF-SHA256 KDF, and the ChaCha20Poly1305 AEAD
• Algorithm Usage Location(s): "alg"
• JOSE Implementation Requirements: Optional
• Change Controller: IETF
• Specification Document(s): of this specification
• Algorithm Analysis Documents(s):

HPKE-5

• Algorithm Name: HPKE-5
• Algorithm Description: Cipher suite for JOSE-HPKE using 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): of this specification
• Algorithm Analysis Documents(s):

HPKE-6

• Algorithm Name: HPKE-6
• Algorithm Description: Cipher suite for JOSE-HPKE using 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): of this specification
• Algorithm Analysis Documents(s):

int

• Algorithm Name: int
• Algorithm Description: Indicates that HPKE Integrated Encryption is being used
• Algorithm Usage Location(s): "enc"
• JOSE Implementation Requirements: Required
• Change Controller: IETF
• Specification Document(s): of this specification
• Algorithm Analysis Documents(s):

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

ek

• Header Parameter Name: "ek"
• Header Parameter Description: A base64url-encoded encapsulated key, as defined in
• Header Parameter Usage Location(s): JWE
• Change Controller: IETF
• Specification Document(s): of this specification

psk_id

• Header Parameter Name: "psk_id"
• Header Parameter Description: A base64url-encoded key identifier (kid) for the pre-shared key, as defined in
• Header Parameter Usage Location(s): JWE
• Change Controller: IETF
• Specification Document(s): of 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. 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. In Proxy Mobile IPv6, packets received from a Mobile Node (MN) by the Mobile Access Gateway (MAG) to which it is attached are typically tunneled to a Local Mobility Anchor (LMA) for routing. The term "localized routing" refers to a method by which packets are routed directly between an MN's MAG and the MAG of its Correspondent Node (CN) without involving any LMA. In a Proxy Mobile IPv6 deployment, it may be desirable to control the establishment of localized routing sessions between two MAGs in a Proxy Mobile IPv6 domain by requiring that the session be authorized. This document specifies how to accomplish this using the Diameter protocol. 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. This specification defines a method for computing a hash value over a JSON Web Key (JWK). It defines which fields in a JWK are used in the hash computation, the method of creating a canonical form for those fields, and how to convert the resulting Unicode string into a byte sequence to be hashed. The resulting hash value can be used for identifying or selecting the key represented by the JWK that is the subject of the thumbprint. IANA n.d. Informative References Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space. Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Tradeverifyd Tradeverifyd This document describes 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 FIPS 204. 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 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. IANA n.d. National Institute of Standards and Technology

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

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

Document History -12

• Added the recipient_structure

-11

• Fix too long lines

-10

• Addressed WGLC review comments by Neil Madden and Sebastian Stenzel.

-09

• Corrected examples.

-08

• Use "enc":"int" for integrated encryption.
• Described reasons for excluding authenticated HPKE.
• Stated that mutually known private information MAY be used as the HPKE info value.

-07

• Clarifications

-06

• Remove auth mode and auth_kid from the specification.
• HPKE AAD for JOSE HPKE Key Encryption is now empty.

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