]> Nokia

Bangalore Karnataka India kondtir@gmail.com

Austria hannes.tschofenig@gmx.net

Nokia

Munich Germany aritra.banerjee@nokia.com

Transmute

United States orie@transmute.industries

independent

United States michael_b_jones@hotmail.com

Security JOSE HPKE JOSE PQC Hybrid This specification defines Hybrid public-key encryption (HPKE) for use with Javascript 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. HPKE utilizes a non-interactive ephemeral-static Diffie-Hellman exchange to establish a shared secret. The motivation for standardizing a public key encryption scheme is explained in the introduction of . The HPKE specification 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, one that authenticates possession of a key encapsulation mechanism (KEM) private key, and one that authenticates possession of both a pre-shared key and a KEM private key. This specification utilizes HPKE as a foundational building block and carries the output to JOSE (, ).

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), a term defined in CMS .
• 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 .
• Key Type (kty), see .

HPKE for JOSE

Overview The JSON Web Algorithms (JWA) in Section 4.6 defines two ways using the key agreement result. When Direct Key Agreement is employed, the shared secret established through the HPKE will be the content encryption key (CEK). When Key Agreement with Key Wrapping is employed, the shared secret established through the HPKE will wrap the CEK. If multiple recipients are needed, then Key Agreement with Key Wrapping mode is used. In both cases a new JOSE header parameter, called 'encapsulated_key', is used to convey the content of the "enc" structure defined in the HPKE specification. "enc" represents the serialized public key. When the alg value is set to any of algorithms registered by this specification then the 'encapsulated_key' header parameter MUST be present in the unprotected header parameter. The 'encapsulated_key' parameter contains the encapsulated key, which is output of the HPKE KEM, and is represented as a base64url encoded string. The parameter "kty" MUST be present and set to "OKP" defined in Section 2 of .

HPKE Usage in Direct and Key Agreement with Key Wrapping In Direct Key Agreement mode, HPKE is employed to directly encrypt the plaintext, and the resulting ciphertext is included in the JWE ciphertext. In Key Agreement with Key Wrapping mode, HPKE is used to encrypt the Content Encryption Key (CEK), and the resulting ciphertext is included in the JWE ciphertext.

HPKE Usage in Direct Key Agreement mode In Direct Key Agreement mode, the sender MUST specify the 'encapsulated_key' and 'alg' parameters in the protected header to indicate the use of HPKE. In this mode, the 'enc' (Encryption Algorithm) parameter MUST NOT be present because the ciphersuite (KEM, KDF, AEAD) is fully-specified in the 'alg' parameter itself. If the 'enc' parameter is present, it MUST be ignored by implementations. This is a deviation from the rule in Section 4.1.2 of . Optionally, the protected header MAY contain the 'kid' parameter used to identify the static recipient public key used by the sender.

HPKE Usage in Key Agreement with Key Wrapping mode In the JWE JSON Serialization, the sender MUST place the 'encapsulated_key' and 'alg' parameters in the per-recipient unprotected header to indicate the use of HPKE. Optionally, the per-recipient unprotected header MAY contain the 'kid' parameter used to identify the static recipient public key used by the sender. In the JWE Compact Serialization, the sender MUST place the 'encapsulated_key' and 'alg' parameters in the protected header to indicate the use of HPKE.

Ciphersuite Registration This specification registers a number of ciphersuites for use with HPKE. A ciphersuite is thereby a combination of several algorithm configurations:

• HPKE Mode
• KEM algorithm
• KDF algorithm
• AEAD algorithm

The "KEM", "KDF", and "AEAD" values are conceptually taken from the HPKE IANA registry . Hence, JOSE-HPKE cannot use an algorithm combination that is not already available with HPKE. For better readability of the algorithm combination ciphersuites labels are build according to the following scheme: --- ]]> The "Mode" indicator may be populated with the following values from 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.

For a list of ciphersuite registrations, please see .

HPKE Encryption and Decryption

HPKE Encryption with SealBase The SealBase(pkR, info, aad, pt) function is used to encrypt a plaintext pt to a recipient's public key (pkR). If "zip" parameter is present, compression is applied to the plaintext pt using the specified compression algorithm before invoking SealBase. Two cases of plaintext need to be distinguished:

• In Direct Key Agreement mode, the plaintext "pt" passed into SealBase is the content to be encrypted. Hence, there is no intermediate layer utilizing a CEK.
• In Key Agreement with Key Wrapping mode, the plaintext "pt" passed into SealBase is the CEK. The CEK is a random byte sequence of length appropriate for the encryption algorithm. For example, AES-128-GCM requires a 16 byte key and the CEK would therefore be 16 bytes long.

In the JWE Compact Serialization, the "aad" parameter in SealBase function will take the Additional Authenticated Data encryption parameter defined in Section 5.1 of as input. In the JWE JSON Serialization, SealBase function will be invoked with empty associated data "aad". The HPKE specification defines the "info" parameter as a context information structure that is used to ensure that the derived keying material is bound to the context of the transaction. The "info" parameter in SealBase function will take the JOSE context specific data defined in Section 4.6.2 of as input. The SealBase function internally creates the sending HPKE context by invoking SetupBaseS() (Section 5.1.1 of ) with "pkR" and "info". This yields the context "sctxt" and an encapsulation key "enc". The SealBase function then invokes the Seal() method on "sctxt" (Section 5.2 of ) with "aad", yielding ciphertext "ct". Note that Section 6 of discusses Single-Shot APIs for encryption and decryption; SetupBaseS internally invokes Seal() method to return both "ct" and "enc". In summary, if SealBase() is successful, it will output a ciphertext "ct" and an encapsulated key "enc". In both modes, 'encapsulated_key' will contain the value of "enc". In Direct Key Agreement mode, the JWE Ciphertext will contain the value of 'ct'. In Key Agreement with Key Wrapping mode, the JWE Encrypted Key will contain the value of 'ct'. In Direct Key Agreement mode, the JWE Encrypted Key will use the value of an empty octet sequence. In both modes, the JWE Initialization Vector value will be an empty octet sequence. In both modes, the JWE Authentication Tag MUST be absent. In both JWE Compact Serialization and the JWE JSON Serialization, "ct" and "enc" will be base64url encoded (see Section 7.1 and 7.2 of ), since JSON lacks a way to directly represent arbitrary octet sequences.

HPKE Decryption with OpenBase The recipient will use the OpenBase(enc, skR, info, aad, ct) function with the base64url decoded "encapsulated_key" and the "ciphertext" parameters received from the sender. The "aad" and the "info" parameters are constructed from Additional Authenticated Data encryption parameter and JOSE context, respectively. The OpenBase internally creates the receiving HPKE context by invoking SetupBaseR() (Section 5.1.1 of ) with "skR", "enc", and "info". This yields the context "rctxt". The OpenBase function then decrypts "ct" by invoking the Open() method on "rctxt" (Section 5.2 of ) with "aad", yielding "pt" or an error on failure. The OpenBase function will, if successful, decrypts "ct". When decrypted, the result will be either the CEK (when Key Agreement with Key Wrapping mode is used), or the content (if Direct Key Agreement mode is used). The CEK is the symmetric key used to decrypt the ciphertext.

Example Hybrid Key Agreement Computation This example uses HPKE-Base-P256-SHA256-AES128GCM which corresponds to the following HPKE algorithm combination:

• KEM: DHKEM(P-256, HKDF-SHA256)
• KDF: HKDF-SHA256
• AEAD: AES-128-GCM
• Mode: Base
• payload: "This is the content"
• aad: ""

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.

IANA Considerations

IANA Considerations This document requests IANA to add new values to the 'JOSE Algorithms' and to the 'JOSE Header Parameters' registries in the 'Standards Action With Expert Review category'.

JOSE Algorithms Registry (Direct Key Agreement)

• Algorithm Name: HPKE-Base-P256-SHA256-AES128GCM
• 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: IESG
• Specification Document(s): [[TBD: This RFC]]
• Algorithm Analysis Documents(s): TODO
• Algorithm Name: HPKE-Base-P384-SHA384-AES256GCM
• 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: IESG
• Specification Document(s): [[TBD: This RFC]]
• Algorithm Analysis Documents(s): TODO
• Algorithm Name: HPKE-Base-P521-SHA512-AES256GCM
• 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: IESG
• Specification Document(s): [[TBD: This RFC]]
• Algorithm Analysis Documents(s): TODO
• Algorithm Name: HPKE-Base-X25519-SHA256-AES128GCM
• 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: IESG
• Specification Document(s): [[TBD: This RFC]]
• Algorithm Analysis Documents(s): TODO
• Algorithm Name: HPKE-Base-X25519-SHA256-ChaCha20Poly1305
• 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"
• JOSE Implementation Requirements: Optional
• Change Controller: IESG
• Specification Document(s): [[TBD: This RFC]]
• Algorithm Analysis Documents(s): TODO
• Algorithm Name: HPKE-Base-X448-SHA512-AES256GCM
• 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: IESG
• Specification Document(s): [[TBD: This RFC]]
• Algorithm Analysis Documents(s): TODO
• Algorithm Name: HPKE-Base-X448-SHA512-ChaCha20Poly1305
• 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: IESG
• Specification Document(s): [[TBD: This RFC]]
• Algorithm Analysis Documents(s): TODO

JOSE Algorithms Registry (Key Agreement with Key Wrapping)

• Algorithm Name: HPKE-Base-P256-SHA256-AES128GCMKW
• Algorithm Description: Cipher suite for JOSE-HPKE in Base Mode that uses the DHKEM(P-256, HKDF-SHA256) KEM, the HKDF-SHA256 KDF and Key wrapping with the AES-128-GCM AEAD.
• Algorithm Usage Location(s): "alg"
• JOSE Implementation Requirements: Optional
• Change Controller: IESG
• Specification Document(s): [[TBD: This RFC]]
• Algorithm Analysis Documents(s): TODO
• Algorithm Name: HPKE-Base-P384-SHA384-AES256GCMKW
• Algorithm Description: Cipher suite for JOSE-HPKE in Base Mode that uses the DHKEM(P-384, HKDF-SHA384) KEM, the HKDF-SHA384 KDF, and Key wrapping with the AES-256-GCM AEAD.
• Algorithm Usage Location(s): "alg"
• JOSE Implementation Requirements: Optional
• Change Controller: IESG
• Specification Document(s): [[TBD: This RFC]]
• Algorithm Analysis Documents(s): TODO
• Algorithm Name: HPKE-Base-P521-SHA512-AES256GCMKW
• Algorithm Description: Cipher suite for JOSE-HPKE in Base Mode that uses the DHKEM(P-521, HKDF-SHA512) KEM, the HKDF-SHA512 KDF, and Key wrapping with the AES-256-GCM AEAD.
• Algorithm Usage Location(s): "alg"
• JOSE Implementation Requirements: Optional
• Change Controller: IESG
• Specification Document(s): [[TBD: This RFC]]
• Algorithm Analysis Documents(s): TODO
• Algorithm Name: HPKE-Base-X25519-SHA256-AES128GCMKW
• Algorithm Description: Cipher suite for JOSE-HPKE in Base Mode that uses the DHKEM(X25519, HKDF-SHA256) KEM, the HKDF-SHA256 KDF, and Key wrapping with the AES-128-GCM AEAD.
• Algorithm Usage Location(s): "alg"
• JOSE Implementation Requirements: Optional
• Change Controller: IESG
• Specification Document(s): [[TBD: This RFC]]
• Algorithm Analysis Documents(s): TODO
• Algorithm Name: HPKE-Base-X25519-SHA256-ChaCha20Poly1305KW
• Algorithm Description: Cipher suite for JOSE-HPKE in Base Mode that uses the DHKEM(X25519, HKDF-SHA256) KEM, the HKDF-SHA256 KDF, and Key wrapping with the ChaCha20Poly1305 AEAD.
• Algorithm Usage Location(s): "alg"
• JOSE Implementation Requirements: Optional
• Change Controller: IESG
• Specification Document(s): [[TBD: This RFC]]
• Algorithm Analysis Documents(s): TODO
• Algorithm Name: HPKE-Base-X448-SHA512-AES256GCMKW
• Algorithm Description: Cipher suite for JOSE-HPKE in Base Mode that uses the DHKEM(X448, HKDF-SHA512) KEM, the HKDF-SHA512 KDF, and Key wrapping with the AES-256-GCM AEAD.
• Algorithm Usage Location(s): "alg"
• JOSE Implementation Requirements: Optional
• Change Controller: IESG
• Specification Document(s): [[TBD: This RFC]]
• Algorithm Analysis Documents(s): TODO
• Algorithm Name: HPKE-Base-X448-SHA512-ChaCha20Poly1305KW
• Algorithm Description: Cipher suite for JOSE-HPKE in Base Mode that uses the DHKEM(X448, HKDF-SHA512) KEM, the HKDF-SHA512 KDF, and Key wrapping with the ChaCha20Poly1305 AEAD.
• Algorithm Usage Location(s): "alg"
• JOSE Implementation Requirements: Optional
• Change Controller: IESG
• Specification Document(s): [[TBD: This RFC]]
• Algorithm Analysis Documents(s): TODO

JOSE Header Parameters

• Parameter Name: "encapsulated_key"
• Parameter Description: HPKE encapsulated key
• Parameter Information Class: Public
• Used with "kty" Value(s): "OKP"
• Change Controller: IESG
• Specification Document(s): [[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. This document defines how to use the Diffie-Hellman algorithms "X25519" and "X448" as well as the signature algorithms "Ed25519" and "Ed448" from the IRTF CFRG elliptic curves work in JSON Object Signing and Encryption (JOSE). 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. 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 document describes the Cryptographic Message Syntax. This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary messages. [STANDARDS-TRACK] IANA Transmute 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.

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