Internet-Draft Use of HPKE in JOSE November 2025
Reddy, et al. Expires 9 May 2026 [Page]
Workgroup:
JOSE
Internet-Draft:
draft-ietf-jose-hpke-encrypt-latest
Updates:
7516 (if approved)
Published:
Intended Status:
Standards Track
Expires:
Authors:
T. Reddy
Nokia
H. Tschofenig
H-BRS
A. Banerjee
Nokia
O. Steele
Tradeverifyd
M. Jones
Self-Issued Consulting

Use of Hybrid Public Key Encryption (HPKE) with JSON Object Signing and Encryption (JOSE)

Abstract

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, and provides security against adaptive chosen ciphertext attacks (IND-CCA2-secure).

HPKE also includes a variant that authenticates possession of a pre-shared key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function.

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

This note is to be removed before publishing as an RFC.

The latest revision of this draft can be found at https://ietf-wg-jose.github.io/draft-ietf-jose-hpke-encrypt/draft-ietf-jose-hpke-encrypt.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-jose-hpke-encrypt/.

Discussion of this document takes place on the jose Working Group mailing list (mailto:jose@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/jose/. Subscribe at https://www.ietf.org/mailman/listinfo/jose/.

Source for this draft and an issue tracker can be found at https://github.com/ietf-wg-jose/draft-ietf-jose-hpke-encrypt.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 9 May 2026.

▲

Table of Contents

1. Introduction

Hybrid Public Key Encryption (HPKE) [I-D.ietf-hpke-hpke] is a public key encryption (PKE) scheme that provides encryption of arbitrary-sized plaintexts given a recipient's public key. This specification enables JSON Web Encryption (JWE) [RFC7516] to leverage HPKE, bringing support for HPKE encryption and KEMs to JWE, and the possibility of utilizing future HPKE algorithms, including hybrid KEMs.

2. Notational Conventions

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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Terminology

This specification uses the following abbreviations and terms:

This specification defines the following terms. When the term is already defined in JWE [RFC7516], the definition below replaces it.

Key Management Mode

A method of determining the Content Encryption Key (CEK) value to use and whether the encryption uses a CEK. Key Management Modes employed by this specification are Key Encryption, Key Wrapping, Direct Key Agreement, Key Agreement with Key Wrapping, Direct Encryption, HPKE Integrated Encryption, and HPKE Key Encryption.

HPKE Integrated Encryption

A Key Management Mode in which HPKE is used to directly encrypt the plaintext without the use of a Content Encryption Key (CEK)

HPKE Key Encryption

A Key Management Mode in which HPKE is used to encrypt the Content Encryption Key (CEK)

4. Overview

This specification defines two new Key Management Modes for use with JWE:

When "alg" is a JOSE-HPKE algorithm:

The HPKE key encapsulation mechanism (KEM), key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function utilized depend on the JOSE-HPKE algorithm used. The HPKE AEAD encryption function is used internally by HPKE and is distinct from the JWE AEAD algorithm specified in "enc".

HPKE supports multiple modes, which are described in Table 1 of [I-D.ietf-hpke-hpke]. In this specification, both "mode_base" and "mode_psk" are utilized. When the "psk_id" JOSE Header parameter is present, the mode used is "mode_psk"; otherwise, the mode used is "mode_base". (This specification does not use the "mode_auth" or "mode_auth_psk" HPKE modes.)

JWE supports both the JWE Compact Serialization, as described in Section 3.1 of [RFC7516], and the JWE JSON Serialization, as described in Section 3.2 of [RFC7516]. Certain JWE features are only supported in specific serializations.

For example, the Compact JWE Serialization does not support:

HPKE Key Encryption can be used with "aad" but only when not expressed with Compact JWE Serialization.

Single recipient HPKE 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 [I-D.ietf-hpke-hpke].

This specification updates the "enc" definition in Section 4.1.2 of [RFC7516] 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 NOT be used and MUST be rejected.

4.1. Auxiliary Authenticated Application Information

The HPKE "aad parameter" for Open() and Seal() specified in Section 8.1 of [I-D.ietf-hpke-hpke] is used with both HPKE Integrated Encryption and HPKE Key Encryption. Its value is the Additional Authenticated Data encryption parameter value computed in Step 14 of Section 8.1.

4.2. Encapsulated Keys

HPKE encapsulated key is defined in Section 5 of [I-D.ietf-hpke-hpke].

In HPKE Integrated Encryption, the JWE Encrypted Key of the sole recipient is the HPKE encapsulated key.

In HPKE Key Encryption, each recipient's JWE Encrypted Key is the encrypted content encryption key, and the value of JOSE Header parameter "ek" is the base64url encoding of the HPKE encapsulated key.

5. HPKE Integrated Encryption

When using HPKE Integrated Encryption:

5.1. Compact Example

Below is an example of a Compact JWE using HPKE integrated encryption:

=============== NOTE: '\' line wrapping per RFC 8792 ================

eyJhbGciOiAiSFBLRS0wIiwgImVuYyI6ICJpbnQiLCAia2lkIjogIkc1Tl9fQ3FNdl9r\
SkdpZUdTRnVBdWd2bDBqclFKQ1ozeUt3Vks2c1VNNG8ifQ.BIh6I40uiBbK8-\
UK7nHdo3ISEfgwJ_MF3zWjQzLt00GhFF2-\
1VgWKHSYLXdeVeRV7AinyocYiCYmISvW0yqiDmc..Ov-\
                                    llz6VUyiw8nZL0OPGLGZckLTm5UcTZFg.

The keys used for this example are in Appendix A.

6. HPKE 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.

When using HPKE Key Encryption:

6.1. JSON Example

Below is an example of a JWE using the JSON Serialization and HPKE key encryption:

=============== NOTE: '\' line wrapping per RFC 8792 ================

{
  "protected": "eyJlbmMiOiAiQTEyOEdDTSJ9",
  "ciphertext": "9AxOd65ROJY1cQ",
  "iv": "2u3NRi3CSr-x7Wuj",
  "tag": "1NKYSWVV4pw5thsq7t6m6Q",
  "recipients": [
    {
      "encrypted_key": "l9VRW1K5CA037fY2ZqVF4bDej413TaAtfjoe3k89-eI",
      "header": {
        "alg": "HPKE-0",
        "kid": "G5N__CqMv_kJGieGSFuAugvl0jrQJCZ3yKwVK6sUM4o",
        "ek": "BJl0V6KLl3HOAZbzFwiAL9eaYbFQPg7-\
             ROmIJpluIQjNS5zultZsC4rGhGzmW1GUWG8bzJUWLQtxFF9oze0AKhU"
      }
    }
  ]
}

The keys used for this example are in Appendix A.

7. Recipient_structure

The Recipient_structure is an input to the HPKE info parameter and provides context information used in key derivation. To ensure compactness and interoperability, this structure is encoded in a binary format. The encoding is as follows:

Recipient_structure = ASCII("JOSE-HPKE rcpt") ||
                      BYTE(255) ||
                      ASCII(content_encryption_alg) ||
                      BYTE(255) ||
                      recipient_extra_info

Where:

7.1. Recipient_structure Example

The Recipient_structure encoded in binary as specified in Section 7, and using the field values (next_layer_alg = "A128GCM", recipient_extra_info = ""), results in the following byte sequence:

"JOSE-HPKE rcpt\xffA128GCM\xff"

The corresponding hexadecimal representation is:

4a4f53452d48504b452072637074ffa131323847434dff

This value is directly used as the HPKE info parameter.

8. Producing and Consuming JWEs

Sections 5.1 (Message Encryption) and 5.2 (Message Decryption) of [RFC7516] are replaced by the following descriptions, which add processing rules for the HPKE Integrated Encryption and HPKE Key Encryption Key Management Modes.

8.1. Message Encryption

The message encryption process is as follows. The order of the steps is not significant in cases where there are no dependencies between the inputs and outputs of the steps.

  1. Determine the Key Management Mode employed by the algorithm used to determine the Content Encryption Key value, when one is used. (This is the algorithm recorded in the alg (algorithm) Header Parameter of the resulting JWE.)

  2. When Key Wrapping, Key Encryption, HPKE Key Encryption, or Key Agreement with Key Wrapping are employed, generate a random CEK value. See [RFC4086] for considerations on generating random values. The CEK MUST have a length equal to that required for the content encryption algorithm.

  3. When Direct Key Agreement or Key Agreement with Key Wrapping are employed, use the key agreement algorithm to compute the value of the agreed upon key. When Direct Key Agreement is employed, let the CEK be the agreed upon key. When Key Agreement with Key Wrapping is employed, the agreed upon key will be used to wrap the CEK.

  4. When Key Wrapping, Key Encryption, HPKE Key Encryption, or Key Agreement with Key Wrapping are employed, encrypt the CEK to the recipient and let the result be the JWE Encrypted Key.

  5. When Direct Key Agreement or Direct Encryption are employed, let the JWE Encrypted Key be the empty octet sequence.

  6. When Direct Encryption is employed, let the CEK be the shared symmetric key.

  7. If HPKE Integrated Encryption is not being employed, compute the encoded key value BASE64URL(JWE Encrypted Key).

  8. If the JWE JSON Serialization is being used, repeat this process (steps 1-7) for each recipient.

  9. Generate a random JWE Initialization Vector of the correct size for the content encryption algorithm (if required for the algorithm); otherwise, let the JWE Initialization Vector be the empty octet sequence.

  10. Compute the encoded Initialization Vector value BASE64URL(JWE Initialization Vector).

  11. If a zip parameter was included, compress the plaintext using the specified compression algorithm and let M be the octet sequence representing the compressed plaintext; otherwise, let M be the octet sequence representing the plaintext.

  12. Create the JSON object(s) containing the desired set of Header Parameters, which together comprise the JOSE Header: one or more of the JWE Protected Header, the JWE Shared Unprotected Header, and the JWE Per-Recipient Unprotected Header.

  13. Compute the Encoded Protected Header value BASE64URL(UTF8(JWE Protected Header)). If the JWE Protected Header is not present (which can only happen when using the JWE JSON Serialization and no protected member is present), let this value be the empty string.

  14. Let the Additional Authenticated Data encryption parameter be ASCII(Encoded Protected Header). However, if a JWE AAD value is present (which can only be the case when using the JWE JSON Serialization), instead let the Additional Authenticated Data encryption parameter be ASCII(Encoded Protected Header || '.' || BASE64URL(JWE AAD)).

  15. Encrypt M using the CEK, the JWE Initialization Vector, and the Additional Authenticated Data value using the specified content encryption algorithm to create the JWE Ciphertext value and the JWE Authentication Tag (which is the Authentication Tag output from the encryption operation) unless HPKE Integrated Encryption is being employed. If HPKE Integrated Encryption is being employed, encrypt M using the specified HPKE algorithm to create the JWE Ciphertext value; in this case, the JWE Initialization Vector and JWE Authentication Tag values are both the empty octet sequence.

  16. Compute the encoded ciphertext value BASE64URL(JWE Ciphertext).

  17. Compute the encoded Authentication Tag value BASE64URL(JWE Authentication Tag).

  18. If a JWE AAD value is present, compute the encoded AAD value BASE64URL(JWE AAD).

  19. Create the desired serialized output. The Compact Serialization of this result is the string BASE64URL(UTF8(JWE Protected Header)) || '.' || BASE64URL(JWE Encrypted Key) || '.' || BASE64URL(JWE Initialization Vector) || '.' || BASE64URL(JWE Ciphertext) || '.' || BASE64URL(JWE Authentication Tag). The JWE JSON Serialization is described in Section 7.2 of [RFC7516].

8.2. Message Decryption

The message decryption process is the reverse of the encryption process. The order of the steps is not significant in cases where there are no dependencies between the inputs and outputs of the steps. If any of these steps fail, the encrypted content cannot be validated.

When there are multiple recipients, it is an application decision which of the recipients' encrypted content must successfully validate for the JWE to be accepted. In some cases, encrypted content for all recipients must successfully validate or the JWE will be considered invalid. In other cases, only the encrypted content for a single recipient needs to be successfully validated. However, in all cases, the encrypted content for at least one recipient MUST successfully validate or the JWE MUST be considered invalid.

  1. Parse the JWE representation to extract the serialized values for the components of the JWE. When using the JWE Compact Serialization, these components are the base64url-encoded representations of the JWE Protected Header, the JWE Encrypted Key, the JWE Initialization Vector, the JWE Ciphertext, and the JWE Authentication Tag, and when using the JWE JSON Serialization, these components also include the base64url-encoded representation of the JWE AAD and the unencoded JWE Shared Unprotected Header and JWE Per-Recipient Unprotected Header values. When using the JWE Compact Serialization, the JWE Protected Header, the JWE Encrypted Key, the JWE Initialization Vector, the JWE Ciphertext, and the JWE Authentication Tag are represented as base64url-encoded values in that order, with each value being separated from the next by a single period ('.') character, resulting in exactly four delimiting period characters being used. The JWE JSON Serialization is described in Section 7.2 of [RFC7516].

  2. Base64url decode the encoded representations of the JWE Protected Header, the JWE Encrypted Key, the JWE Initialization Vector, the JWE Ciphertext, the JWE Authentication Tag, and the JWE AAD, following the restriction that no line breaks, whitespace, or other additional characters have been used.

  3. Verify that the octet sequence resulting from decoding the encoded JWE Protected Header is a UTF-8-encoded representation of a completely valid JSON object conforming to [RFC8259]; let the JWE Protected Header be this JSON object.

  4. If using the JWE Compact Serialization, let the JOSE Header be the JWE Protected Header. Otherwise, when using the JWE JSON Serialization, let the JOSE Header be the union of the members of the JWE Protected Header, the JWE Shared Unprotected Header and the corresponding JWE Per-Recipient Unprotected Header, all of which must be completely valid JSON objects. During this step, verify that the resulting JOSE Header does not contain duplicate Header Parameter names. When using the JWE JSON Serialization, this restriction includes that the same Header Parameter name also MUST NOT occur in distinct JSON object values that together comprise the JOSE Header.

  5. Verify that the implementation understands and can process all fields that it is required to support, whether required by this specification, by the algorithms being used, or by the crit Header Parameter value, and that the values of those parameters are also understood and supported.

  6. Determine the Key Management Mode employed by the algorithms specified by the Header Parameters. If alg is not a JOSE-HPKE algorithm then the Key Management Mode is determined by the alg value. If alg is a JOSE-HPKE algorithm then when the enc value is int, the Key Management Mode is HPKE Integrated Encryption; if alg is a JOSE-HPKE algorithm then when the enc value is not int, the Key Management Mode is HPKE Key Encryption.

  7. Verify that the JWE uses a key known to the recipient.

  8. When Direct Key Agreement or Key Agreement with Key Wrapping are employed, use the key agreement algorithm to compute the value of the agreed upon key. When Direct Key Agreement is employed, let the CEK be the agreed upon key. When Key Agreement with Key Wrapping is employed, the agreed upon key will be used to decrypt the JWE Encrypted Key.

  9. When Key Wrapping, Key Encryption, HPKE Key Encryption, or Key Agreement with Key Wrapping are employed, decrypt the JWE Encrypted Key to produce the CEK. The CEK MUST have a length equal to that required for the content encryption algorithm. Note that when there are multiple recipients, each recipient will only be able to decrypt JWE Encrypted Key values that were encrypted to a key in that recipient's possession. It is therefore normal to only be able to decrypt one of the per-recipient JWE Encrypted Key values to obtain the CEK value. Also, see Section 11.5 of [RFC7516] for security considerations on mitigating timing attacks.

  10. When Direct Key Agreement, Direct Encryption, or HPKE Integrated Encryption are employed, verify that the JWE Encrypted Key value is an empty octet sequence.

  11. When Direct Encryption is employed, let the CEK be the shared symmetric key.

  12. If HPKE Integrated Encryption is not being employed, record whether the CEK could be successfully determined for this recipient or not.

  13. If the JWE JSON Serialization is being used, repeat this process (steps 4-12) for each recipient contained in the representation.

  14. Compute the Encoded Protected Header value BASE64URL(UTF8(JWE Protected Header)). If the JWE Protected Header is not present (which can only happen when using the JWE JSON Serialization and no protected member is present), let this value be the empty string.

  15. Let the Additional Authenticated Data encryption parameter be ASCII(Encoded Protected Header). However, if a JWE AAD value is present (which can only be the case when using the JWE JSON Serialization), instead let the Additional Authenticated Data encryption parameter be ASCII(Encoded Protected Header || '.' || BASE64URL(JWE AAD)).

  16. Decrypt the JWE Ciphertext using the CEK, the JWE Initialization Vector, the Additional Authenticated Data value, and the JWE Authentication Tag (which is the Authentication Tag input to the calculation) using the specified content encryption algorithm, returning the decrypted plaintext and validating the JWE Authentication Tag in the manner specified for the algorithm, rejecting the input without emitting any decrypted output if the JWE Authentication Tag is incorrect unless HPKE Integrated Encryption is being employed. If HPKE Integrated Encryption is being employed, decrypt the JWE Ciphertext using the specified HPKE algorithm returning the decrypted plaintext in the manner specified for the algorithm, rejecting the input without emitting any decrypted output if the HPKE decryption fails.

  17. If a zip parameter was included, uncompress the decrypted plaintext using the specified compression algorithm.

  18. If there was no recipient for which all of the decryption steps succeeded, then the JWE MUST be considered invalid. Otherwise, output the plaintext. In the JWE JSON Serialization case, also return a result to the application indicating for which of the recipients the decryption succeeded and failed.

Finally, note that it is an application decision which algorithms may be used in a given context. Even if a JWE can be successfully decrypted, unless the algorithms used in the JWE are acceptable to the application, it SHOULD consider the JWE to be invalid.

9. 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 Figure 1.

+---------------------+-----------------+
| JWE Algorithm       | JWK |           |
|                     | kty | crv       |
+---------------------+-----+-----------+
| HPKE-0, HPKE-7      | EC  | P-256     |
| HPKE-1              | EC  | P-384     |
| HPKE-2              | EC  | P-521     |
| HPKE-3, HPKE-4      | OKP | X25519    |
| HPKE-5, HPKE-6      | OKP | X448      |
+---------------------+-----+-----------+
Figure 1: JWK Types and Curves for JOSE-HPKE Ciphersuites

9.1. 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:

{
  "kty": "OKP",
  "crv": "X25519",
  "x": "3pPHgcHYVYpOpB6ISwHdoPRB6jNgd8mM4nRyyj4H3aE",
  "d": "nWGxne0tAiV8Hk6kcy4rN0wMskjl9yND0N3Xeho9n6g",
  "kid": "recipient-key-1",
  "alg": "HPKE-3",
  "key_ops": "encrypt"
}

It uses the "key_ops" value of "encrypt", which is appropriate when using integrated encryption.

10. Security Considerations

This specification is based on HPKE and the security considerations of [I-D.ietf-hpke-hpke] 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 [RFC4086] applies.

10.1. Key Management

A single KEM key MUST NOT be used with multiple KEM 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.

10.2. Review JWT Best Current Practices

The guidance in [RFC8725] about encryption is also pertinent to this specification.

11. 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:

The "KEM", "KDF", and "AEAD" values are chosen from the IANA HPKE registry [IANA.HPKE].

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.

12. IANA Considerations

12.1. JSON Web Signature and Encryption Algorithms

The following entries are added to the IANA "JSON Web Signature and Encryption Algorithms" registry [IANA.JOSE] established by [RFC7518]:

12.1.1. 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): Section 9 of this specification

  • Algorithm Analysis Documents(s): [I-D.ietf-hpke-hpke]

12.1.2. 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): Section 9 of this specification

  • Algorithm Analysis Documents(s): [I-D.ietf-hpke-hpke]

12.1.3. 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): Section 9 of this specification

  • Algorithm Analysis Documents(s): [I-D.ietf-hpke-hpke]

12.1.4. 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): Section 9 of this specification

  • Algorithm Analysis Documents(s): [I-D.ietf-hpke-hpke]

12.1.5. 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): Section 9 of this specification

  • Algorithm Analysis Documents(s): [I-D.ietf-hpke-hpke]

12.1.6. 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): Section 9 of this specification

  • Algorithm Analysis Documents(s): [I-D.ietf-hpke-hpke]

12.1.7. 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): Section 9 of this specification

  • Algorithm Analysis Documents(s): [I-D.ietf-hpke-hpke]

12.1.8. HPKE-7

  • Algorithm Name: HPKE-7

  • Algorithm Description: Cipher suite for JOSE-HPKE using the DHKEM(P-256, HKDF-SHA256) KEM, the HKDF-SHA256 KDF and the A256GCM AEAD

  • Algorithm Usage Location(s): "alg"

  • JOSE Implementation Requirements: Optional

  • Change Controller: IETF

  • Specification Document(s): Section 9 of this specification

  • Algorithm Analysis Documents(s): [I-D.ietf-hpke-hpke]

12.1.9. 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): Section 4 of this specification

  • Algorithm Analysis Documents(s): [I-D.ietf-hpke-hpke]

12.2. JSON Web Signature and Encryption Header Parameters

The following entries are added to the IANA "JSON Web Key Parameters" registry [IANA.JOSE]:

12.2.1. ek

  • Header Parameter Name: "ek"

  • Header Parameter Description: A base64url-encoded encapsulated key, as defined in Section 5 of [I-D.ietf-hpke-hpke]

  • Header Parameter Usage Location(s): JWE

  • Change Controller: IETF

  • Specification Document(s): Section 4.2 of this specification

12.2.2. psk_id

  • Header Parameter Name: "psk_id"

  • Header Parameter Description: A base64url-encoded key identifier (kid) for the pre-shared key, as defined in Section 5.1.2 of [I-D.ietf-hpke-hpke]

  • Header Parameter Usage Location(s): JWE

  • Change Controller: IETF

  • Specification Document(s): Section 4 of this specification

13. References

13.1. Normative References

[I-D.ietf-hpke-hpke]
Barnes, R., Bhargavan, K., Lipp, B., and C. A. Wood, "Hybrid Public Key Encryption", Work in Progress, Internet-Draft, draft-ietf-hpke-hpke-02, , <https://datatracker.ietf.org/doc/html/draft-ietf-hpke-hpke-02>.
[IANA.JOSE]
IANA, "JSON Web Signature and Encryption Algorithms", n.d., <https://www.iana.org/assignments/jose>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC7516]
Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, , <https://www.rfc-editor.org/rfc/rfc7516>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8259]
Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, , <https://www.rfc-editor.org/rfc/rfc8259>.
[RFC8725]
Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", BCP 225, RFC 8725, DOI 10.17487/RFC8725, , <https://www.rfc-editor.org/rfc/rfc8725>.

13.2. Informative References

[I-D.ietf-cose-hpke]
Tschofenig, H., Steele, O., Daisuke, A., and L. Lundblade, "Use of Hybrid Public-Key Encryption (HPKE) with CBOR Object Signing and Encryption (COSE)", Work in Progress, Internet-Draft, draft-ietf-cose-hpke-18, , <https://datatracker.ietf.org/doc/html/draft-ietf-cose-hpke-18>.
[IANA.HPKE]
IANA, "Hybrid Public Key Encryption (HPKE)", n.d., <https://www.iana.org/assignments/hpke>.
[NIST.SP.800-56Ar3]
National Institute of Standards and Technology, "Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography, NIST Special Publication 800-56A Revision 3", , <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf>.
[RFC4086]
Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, , <https://www.rfc-editor.org/rfc/rfc4086>.
[RFC7518]
Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, , <https://www.rfc-editor.org/rfc/rfc7518>.

Appendix A. Keys Used in Examples

This private key and its implied public key are used the examples:

{
  "kty": "EC",
  "use": "enc",
  "alg": "HPKE-0",
  "kid": "G5N__CqMv_kJGieGSFuAugvl0jrQJCZ3yKwVK6sUM4o",
  "crv": "P-256",
  "x": "gixQJ0qg4Ag-6HSMaIEDL_zbDhoXavMyKlmdn__AQVE",
  "y": "ZxTgRLWaKONCL_GbZKLNPsW9EW6nBsN4AwQGEFAFFbM",
  "d": "g2DXtKapi2oN2zL_RCWX8D4bWURHCKN2-ZNGC05ZaR8"
}

Acknowledgments

This specification leverages text from [I-D.ietf-cose-hpke]. We would like to thank Richard Barnes, Brian Campbell, Matt Chanda, Ilari Liusvaara, Neil Madden, Aaron Parecki, Filip Skokan, and Sebastian Stenzel for their contributions to the specification.

Document History

-15

-14

-13

-12

-11

-10

-09

-08

-07

-06

-05

-04

-03

-02

-01

-00

Authors' Addresses

Tirumaleswar Reddy
Nokia
Bangalore
Karnataka
India
Hannes Tschofenig
University of Applied Sciences Bonn-Rhein-Sieg
Germany
Aritra Banerjee
Nokia
London
United Kingdom
Orie Steele
Tradeverifyd
United States
Michael B. Jones
Self-Issued Consulting
United States
URI: https://self-issued.info/