]>
Use of Hybrid PublicKey Encryption (HPKE) with Javascript Object Signing and Encryption (JOSE)
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 publickey encryption (HPKE) for use with
Javascript Object Signing and Encryption (JOSE). HPKE offers a variant of
publickey encryption of arbitrarysized 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
JOSEnative 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 publickey encryption (HPKE) is a scheme that
provides public key encryption of arbitrarysized plaintexts given a
recipient's public key. HPKE utilizes a noninteractive ephemeralstatic
DiffieHellman 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
arbitrarysized plaintexts for a recipient public key. It also
includes three authenticated variants, including one that authenticates
possession of a preshared key, one that authenticates possession of
a key encapsulation mechanism (KEM) private key, and one that
authenticates possession of both a preshared 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:

Contentencryption 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.
In both modes, the sender MUST specify the 'alg' parameter in the protected header to indicate the use of HPKE.
HPKE Usage in Direct Key Agreement mode
The sender MUST place the 'encapsulated_key' parameter in the protected header. 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' parameter in the perrecipient unprotected header. Optionally, the perrecipient unprotected header MAY contain the 'kid' parameter used to identify the static recipient public key used by the sender.
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, JOSEHPKE 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 preshared 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).
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, AES128GCM
requires a 16 byte key and the CEK would therefore be 16 bytes long.
The "aad" parameter in SealBase function will take the JWE AAD value as input when the JWE AAD value is nonempty; otherwise, it will take an empty 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 {RFC9180} discusses SingleShot 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 JWE Compact Serialization and the JWE JSON Serialization, "ct" and "enc" will be base64url encoded, since JSON lacks a way to directly represent arbitrary octet sequences.
In both modes, "encapsulated_key" will contain the value of BASE64URL(enc). In Direct Key Agreement mode, JWE Ciphertext will contain the value of BASE64URL(ct). In Key Agreement with Key Wrapping mode, JWE Encrypted Key will contain the value of BASE64URL(ct). In Direct Key Agreement mode, JWE Encrypted Key will use the value of empty octet sequence.
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 JWE AAD 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.
PostQuantum Considerations
The migration to PostQuantum Cryptography (PQC) is unique in the history of modern digital cryptography in that neither the traditional algorithms nor the postquantum algorithms are fully trusted to protect data for the required data lifetimes. The traditional algorithms, such as RSA and elliptic curve, will fall to quantum cryptalanysis, while the postquantum algorithms face uncertainty about the underlying mathematics, compliance issues, unknown vulnerabilities, hardware and software implementations that have not had sufficient maturing time to rule out classical cryptanalytic attacks and implementation bugs.
Hybrid key exchange refers to using multiple key exchange algorithms simultaneously and combining the result with the goal of providing security even if all but one of the component algorithms is broken. It is motivated by transition to postquantum cryptography. HPKE can be extended to support hybrid postquantum Key Encapsulation Mechanisms (KEMs) as defined in . Kyber, which is a KEM does not support the staticephemeral key exchange that allows HPKE based on DH based KEMs and its optional authenticated modes as discussed in Section 1.2 of .
The JOSE HPKE PQ/T hybrid ciphersuites are defined in .
Example Hybrid Key Agreement Computation
This example uses HPKEBaseP256SHA256AES128GCM which corresponds
to the following HPKE algorithm combination:

KEM: DHKEM(P256, HKDFSHA256)

KDF: HKDFSHA256

AEAD: AES128GCM

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
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: HPKEBaseP256SHA256AES128GCM

Algorithm Description: Cipher suite for JOSEHPKE version 1 in Base Mode that uses the DHKEM(P256, HKDFSHA256) KEM, the HKDFSHA256 KDF and the AES128GCM 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: HPKEBaseP256SHA256ChaCha20Poly1305

Algorithm Description: Cipher suite for JOSEHPKE version 1 in Base Mode that uses the DHKEM(P256, HKDFSHA256) KEM, the HKDFSHA256 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: HPKEBaseP384SHA384AES256GCM

Algorithm Description: Cipher suite for JOSEHPKE version 1 in Base Mode that uses the DHKEM(P384, HKDFSHA384) KEM, the HKDFSHA384 KDF, and the AES256GCM 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: HPKEBaseP384SHA384ChaCha20Poly1305

Algorithm Description: Cipher suite for JOSEHPKE version 1 in Base Mode that uses the DHKEM(P384, HKDFSHA384) KEM, the HKDFSHA384 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: HPKEBaseP521SHA512AES256GCM

Algorithm Description: Cipher suite for JOSEHPKE version 1 in Base Mode that uses the DHKEM(P521, HKDFSHA512) KEM, the HKDFSHA512 KDF, and the AES256GCM 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: HPKEBaseP521SHA512ChaCha20Poly1305

Algorithm Description: Cipher suite for JOSEHPKE version 1 in Base Mode that uses the DHKEM(P521, HKDFSHA512) KEM, the HKDFSHA512 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: HPKEBaseX25519SHA256AES128GCM

Algorithm Description: Cipher suite for JOSEHPKE version 1 in Base Mode that uses the DHKEM(X25519, HKDFSHA256) KEM, the HKDFSHA256 KDF, and the AES128GCM 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: HPKEBaseX25519SHA256ChaCha20Poly1305

Algorithm Description: Cipher suite for JOSEHPKE version 1 in Base Mode that uses the DHKEM(X25519, HKDFSHA256) KEM, the HKDFSHA256 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: HPKEBaseX448SHA512AES256GCM

Algorithm Description: Cipher suite for JOSEHPKE version 1 in Base Mode that uses the DHKEM(X448, HKDFSHA512) KEM, the HKDFSHA512 KDF, and the AES256GCM 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: HPKEBaseX448SHA512ChaCha20Poly1305

Algorithm Description: Cipher suite for JOSEHPKE version 1 in Base Mode that uses the DHKEM(X448, HKDFSHA512) KEM, the HKDFSHA512 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: HPKEBaseX25519Kyber768SHA256AES256GCM

Algorithm Description: Cipher suite for JOSEHPKE version 1 in Base Mode that uses the X25519Kyber768Draft00 Hybrid KEM, the HKDFSHA256 KDF, and the AES256GCM 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: HPKEBaseX25519Kyber768SHA256ChaCha20Poly1305

Algorithm Description: Cipher suite for JOSEHPKE version 1 in Base Mode that uses the X25519Kyber768Draft00 Hybrid KEM, the HKDFSHA256 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: HPKEBaseCP256SHA256ChaCha20Poly1305

Algorithm Description: Cipher suite for JOSEHPKE version 1 in Base Mode that uses the DHKEM(CP256, HKDFSHA256) KEM, the HKDFSHA256 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:HPKEBaseCP384SHA512ChaCha20Poly1305

Algorithm Description: Cipher suite for JOSEHPKE in Base Mode that uses the DHKEM(CP384, HKDFSHA512) KEM, the HKDFSHA512 KDF, and the AES256GCM 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: HPKEBaseCP521SHA512ChaCha20Poly1305

Algorithm Description: Cipher suite for JOSEHPKE version 1 in Base Mode that uses the DHKEM(CP521, HKDFSHA512) KEM, the HKDFSHA512 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: HPKEBaseCP256SHA256AES128GCM

Algorithm Description: Cipher suite for JOSEHPKE in Base Mode that uses the DHKEM(CP256, HKDFSHA256) KEM, the HKDFSHA256 KDF and the AES128GCM 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: HPKEBaseCP384SHA512AES256GCM

Algorithm Description: Cipher suite for JOSEHPKE in Base Mode that uses the DHKEM(CP384, HKDFSHA512) KEM, the HKDFSHA512 KDF, and the AES256GCM 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: HPKEBaseCP521SHA512AES256GCM

Algorithm Description: Cipher suite for JOSEHPKE in Base Mode that uses the DHKEM(CP521, HKDFSHA512) KEM, the HKDFSHA512 KDF, and the AES256GCM 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: HPKEBaseP256SHA256AES128GCMKW

Algorithm Description: Cipher suite for JOSEHPKE version 1 in Base Mode that uses the DHKEM(P256, HKDFSHA256) KEM, the HKDFSHA256 KDF and Key wrapping with the AES128GCM 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: HPKEBaseP256SHA256ChaCha20Poly1305KW

Algorithm Description: Cipher suite for JOSEHPKE version 1 in Base Mode that uses the DHKEM(P256, HKDFSHA256) KEM, the HKDFSHA256 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: HPKEBaseP384SHA384AES256GCMKW

Algorithm Description: Cipher suite for JOSEHPKE version 1 in Base Mode that uses the DHKEM(P384, HKDFSHA384) KEM, the HKDFSHA384 KDF, and Key wrapping with the AES256GCM 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: HPKEBaseP384SHA384ChaCha20Poly1305KW

Algorithm Description: Cipher suite for JOSEHPKE version 1 in Base Mode that uses the DHKEM(P384, HKDFSHA384) KEM, the HKDFSHA384 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: HPKEBaseP521SHA512AES256GCMKW

Algorithm Description: Cipher suite for JOSEHPKE version 1 in Base Mode that uses the DHKEM(P521, HKDFSHA512) KEM, the HKDFSHA512 KDF, and Key wrapping with the AES256GCM 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: HPKEBaseP521SHA512ChaCha20Poly1305KW

Algorithm Description: Cipher suite for JOSEHPKE version 1 in Base Mode that uses the DHKEM(P521, HKDFSHA512) KEM, the HKDFSHA512 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: HPKEBaseX25519SHA256AES128GCMKW

Algorithm Description: Cipher suite for JOSEHPKE version 1 in Base Mode that uses the DHKEM(X25519, HKDFSHA256) KEM, the HKDFSHA256 KDF, and Key wrapping with the AES128GCM 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: HPKEBaseX25519SHA256ChaCha20Poly1305KW

Algorithm Description: Cipher suite for JOSEHPKE version 1 in Base Mode that uses the DHKEM(X25519, HKDFSHA256) KEM, the HKDFSHA256 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: HPKEBaseX448SHA512AES256GCMKW

Algorithm Description: Cipher suite for JOSEHPKE version 1 in Base Mode that uses the DHKEM(X448, HKDFSHA512) KEM, the HKDFSHA512 KDF, and Key wrapping with the AES256GCM 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: HPKEBaseX448SHA512ChaCha20Poly1305KW

Algorithm Description: Cipher suite for JOSEHPKE version 1 in Base Mode that uses the DHKEM(X448, HKDFSHA512) KEM, the HKDFSHA512 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: HPKEBaseX25519Kyber768SHA256AES256GCMKW

Algorithm Description: Cipher suite for JOSEHPKE version 1 in Base Mode that uses the X25519Kyber768Draft00 Hybrid KEM, the HKDFSHA256 KDF, and Key wrapping with the AES256GCM 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: HPKEBaseX25519Kyber768SHA256ChaCha20Poly1305KW

Algorithm Description: Cipher suite for JOSEHPKE version 1 in Base Mode that uses the X25519Kyber768Draft00 Hybrid KEM, the HKDFSHA256 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: HPKEBaseCP256SHA256ChaCha20Poly1305KW

Algorithm Description: Cipher suite for JOSEHPKE version 1 in Base Mode that uses the DHKEM(CP256, HKDFSHA256) KEM, the HKDFSHA256 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: HPKEBaseCP521SHA512ChaCha20Poly1305KW

Algorithm Description: Cipher suite for JOSEHPKE version 1 in Base Mode that uses the DHKEM(CP521, HKDFSHA512) KEM, the HKDFSHA512 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: HPKEBaseCP256SHA256AES128GCMKW

Algorithm Description: Cipher suite for JOSEHPKE in Base Mode that uses the DHKEM(CP256, HKDFSHA256) KEM, the HKDFSHA256 KDF and Key wrapping with the AES128GCM 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: HPKEBaseCP384SHA512AES256GCMKW

Algorithm Description: Cipher suite for JOSEHPKE in Base Mode that uses the DHKEM(CP384, HKDFSHA512) KEM, the HKDFSHA512 KDF, and Key wrapping with the AES256GCM 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: HPKEBaseCP521SHA512AES256GCMKW

Algorithm Description: Cipher suite for JOSEHPKE in Base Mode that uses the DHKEM(CP521, HKDFSHA512) KEM, the HKDFSHA512 KDF, and Key wrapping with the AES256GCM 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
Key words for use in RFCs to Indicate Requirement Levels
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.
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
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.
Hybrid Public Key Encryption
This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrarysized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a preshared 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 DiffieHellman (ECDH) key agreement, HMACbased 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)
JSON Web Encryption (JWE) represents encrypted content using JSONbased 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.
JSON Web Algorithms (JWA)
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.
CFRG Elliptic Curve DiffieHellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE)
This document defines how to use the DiffieHellman 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).
JSON Web Key (JWK)
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 Improvements for Security Protocols
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 longterm 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.
Cryptographic Message Syntax
This document describes the Cryptographic Message Syntax. This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary messages. [STANDARDSTRACK]
Hybrid Public Key Encryption (HPKE) IANA Registry
IANA
X25519Kyber768Draft00 hybrid postquantum KEM for HPKE
Cloudflare
Cloudflare
This memo defines X25519Kyber768Draft00, a hybrid postquantum KEM,
for HPKE (RFC9180). This KEM does not support the authenticated
modes of HPKE.
Use of Hybrid PublicKey Encryption (HPKE) with CBOR Object Signing and Encryption (COSE)
Transmute
Security Theory LLC
This specification defines hybrid publickey encryption (HPKE) for
use with CBOR Object Signing and Encryption (COSE). HPKE offers a
variant of publickey encryption of arbitrarysized 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 COSEnative 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.