



JOSE                                                            T. Reddy
Internet-Draft                                                     Nokia
Intended status: Standards Track                           H. Tschofenig
Expires: 8 January 2026                                            H-BRS
                                                             A. Banerjee
                                                                   Nokia
                                                               O. Steele
                                                            Tradeverifyd
                                                                M. Jones
                                                  Self-Issued Consulting
                                                             7 July 2025


Use of Hybrid Public Key Encryption (HPKE) with JSON Object Signing and
                           Encryption (JOSE)
                    draft-ietf-jose-hpke-encrypt-11

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.

   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

   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.




Reddy, et al.            Expires 8 January 2026                 [Page 1]

Internet-Draft             Use of HPKE in JOSE                 July 2025


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 8 January 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  Conventions and Terminology . . . . . . . . . . . . . . . . .   3
   4.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Auxiliary Authenticated Application Information . . . . .   5
     4.2.  Encapsulated Keys . . . . . . . . . . . . . . . . . . . .   5
   5.  Integrated Encryption . . . . . . . . . . . . . . . . . . . .   5
     5.1.  Compact Example . . . . . . . . . . . . . . . . . . . . .   6
   6.  Key Encryption  . . . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  JSON Example  . . . . . . . . . . . . . . . . . . . . . .   8
   7.  Mapping HPKE Keys to JWK for JOSE . . . . . . . . . . . . . .   8
     7.1.  JWK Representation of a JOSE-HPKE Key with HPKE
           Ciphersuite . . . . . . . . . . . . . . . . . . . . . . .   9
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
     8.1.  Key Management  . . . . . . . . . . . . . . . . . . . . .  10



Reddy, et al.            Expires 8 January 2026                 [Page 2]

Internet-Draft             Use of HPKE in JOSE                 July 2025


     8.2.  Static Asymmetric Authentication in HPKE  . . . . . . . .  10
     8.3.  Review JWT Best Current Practices . . . . . . . . . . . .  10
   9.  Ciphersuite Registration  . . . . . . . . . . . . . . . . . .  10
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
     10.1.  JSON Web Signature and Encryption Algorithms . . . . . .  11
       10.1.1.  HPKE-0 . . . . . . . . . . . . . . . . . . . . . . .  11
       10.1.2.  HPKE-1 . . . . . . . . . . . . . . . . . . . . . . .  11
       10.1.3.  HPKE-2 . . . . . . . . . . . . . . . . . . . . . . .  12
       10.1.4.  HPKE-3 . . . . . . . . . . . . . . . . . . . . . . .  12
       10.1.5.  HPKE-4 . . . . . . . . . . . . . . . . . . . . . . .  12
       10.1.6.  HPKE-5 . . . . . . . . . . . . . . . . . . . . . . .  13
       10.1.7.  HPKE-6 . . . . . . . . . . . . . . . . . . . . . . .  13
       10.1.8.  int  . . . . . . . . . . . . . . . . . . . . . . . .  13
     10.2.  JSON Web Signature and Encryption Header Parameters  . .  14
       10.2.1.  ek . . . . . . . . . . . . . . . . . . . . . . . . .  14
       10.2.2.  psk_id . . . . . . . . . . . . . . . . . . . . . . .  14
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  14
     11.2.  Informative References . . . . . . . . . . . . . . . . .  15
   Appendix A.  Keys Used in Examples  . . . . . . . . . . . . . . .  16
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  16
   Document History  . . . . . . . . . . . . . . . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

1.  Introduction

   Hybrid Public Key Encryption (HPKE) [RFC9180] 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.

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

3.  Conventions and Terminology

   This specification uses the following abbreviations and terms:

   *  Content Encryption Key (CEK), is defined in [RFC7517].




Reddy, et al.            Expires 8 January 2026                 [Page 3]

Internet-Draft             Use of HPKE in JOSE                 July 2025


   *  Hybrid Public Key Encryption (HPKE) is defined in [RFC9180].

   *  pkR is the public key of the recipient, as defined in [RFC9180].

   *  skR is the private key of the recipient, as defined in [RFC9180].

   *  Key Encapsulation Mechanism (KEM), see [RFC9180].

   *  Key Derivation Function (KDF), see [RFC9180].

   *  Authenticated Encryption with Associated Data (AEAD), see
      [RFC9180].

   *  Additional Authenticated Data (AAD), see [RFC9180].

4.  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
   [RFC9180].

   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 Section 3.1 of [RFC7516], General JWE
   JSON Serialization as described in Section 3.2 of [RFC7516].

   Certain JWE features are only supported in specific serializations.



Reddy, et al.            Expires 8 January 2026                 [Page 4]

Internet-Draft             Use of HPKE in JOSE                 July 2025


   For example Compact JWE Serialization does not support the following:

   *  additional authenticated data

   *  multiple recipients

   *  unprotected headers

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

   Single recipient HPKE JWE Key Encryption with no "aad" can be
   expressed in Compact JWE Serialization, so long as the recipient and
   sender use the same HPKE Setup process as described in Section 5 of
   [RFC9180].

   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 be rejected.

4.1.  Auxiliary Authenticated Application Information

   The HPKE "aad parameter" for Open() and Seal() specified in
   Section 8.1 of [RFC9180] 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
   Section 5.1 of [RFC7518] (Message Encryption).

   Despite similarities to ECDH-ES, this specification does not use the
   apu and apv header parameters, which are described in Section 4.6.1
   of [RFC7518].

4.2.  Encapsulated Keys

   HPKE encapsulated key is defined in Section 5.1.1 of [RFC9180].

   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.

5.  Integrated Encryption

   In HPKE JWE Integrated Encryption:




Reddy, et al.            Expires 8 January 2026                 [Page 5]

Internet-Draft             Use of HPKE in JOSE                 July 2025


   *  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 Section 4.1.2 of
      [RFC7516] 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
      Section 5.1.1 of [RFC9180].

   *  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 Section 5.2 of
      [RFC9180].

   *  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
      [NIST.SP.800-56Ar3] 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 Section 5.1 of [RFC7516].

   *  Then follow Steps 11-19 of Section 5.1 of [RFC7516] (Message
      Encryption).

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

5.1.  Compact Example

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






Reddy, et al.            Expires 8 January 2026                 [Page 6]

Internet-Draft             Use of HPKE in JOSE                 July 2025


   =============== 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.  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 defaults to the empty string; mutually
      known private information MAY be used instead.

   *  The HPKE AAD parameter MUST be set to the empty string.

   *  THE HPKE plaintext MUST be set to the CEK.






Reddy, et al.            Expires 8 January 2026                 [Page 7]

Internet-Draft             Use of HPKE in JOSE                 July 2025


   The processing of "enc", "iv", "tag", "aad", and "ciphertext" is as
   already defined in [RFC7516].  Implementations process these
   parameters as defined in [RFC7516]; no additional processing
   requirements are introduced by HPKE-based 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.  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              | 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      |
   +---------------------+-----+-----------+



Reddy, et al.            Expires 8 January 2026                 [Page 8]

Internet-Draft             Use of HPKE in JOSE                 July 2025


         Figure 1: JWK Types and Curves for JOSE-HPKE Ciphersuites

   When the "kty" field is "AKP" (Algorithm Key Pair
   [I-D.ietf-cose-dilithium]) 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.

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

8.  Security Considerations

   This specification is based on HPKE and the security considerations
   of [RFC9180] 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.










Reddy, et al.            Expires 8 January 2026                 [Page 9]

Internet-Draft             Use of HPKE in JOSE                 July 2025


8.1.  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.

8.2.  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.

8.3.  Review JWT Best Current Practices

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

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




Reddy, et al.            Expires 8 January 2026                [Page 10]

Internet-Draft             Use of HPKE in JOSE                 July 2025


   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.

10.  IANA Considerations

10.1.  JSON Web Signature and Encryption Algorithms

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

10.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 7 of this specification

   *  Algorithm Analysis Documents(s): [RFC9180]

10.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 7 of this specification




Reddy, et al.            Expires 8 January 2026                [Page 11]

Internet-Draft             Use of HPKE in JOSE                 July 2025


   *  Algorithm Analysis Documents(s): [RFC9180]

10.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 7 of this specification

   *  Algorithm Analysis Documents(s): [RFC9180]

10.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 7 of this specification

   *  Algorithm Analysis Documents(s): [RFC9180]

10.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"




Reddy, et al.            Expires 8 January 2026                [Page 12]

Internet-Draft             Use of HPKE in JOSE                 July 2025


   *  JOSE Implementation Requirements: Optional

   *  Change Controller: IETF

   *  Specification Document(s): Section 7 of this specification

   *  Algorithm Analysis Documents(s): [RFC9180]

10.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 7 of this specification

   *  Algorithm Analysis Documents(s): [RFC9180]

10.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 7 of this specification

   *  Algorithm Analysis Documents(s): [RFC9180]

10.1.8.  int

   *  Algorithm Name: int




Reddy, et al.            Expires 8 January 2026                [Page 13]

Internet-Draft             Use of HPKE in JOSE                 July 2025


   *  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): [RFC9180]

10.2.  JSON Web Signature and Encryption Header Parameters

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

10.2.1.  ek

   *  Header Parameter Name: "ek"

   *  Header Parameter Description: A base64url-encoded encapsulated
      key, as defined in Section 5.1.1 of [RFC9180]

   *  Header Parameter Usage Location(s): JWE

   *  Change Controller: IETF

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

10.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
      [RFC9180]

   *  Header Parameter Usage Location(s): JWE

   *  Change Controller: IETF

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

11.  References

11.1.  Normative References



Reddy, et al.            Expires 8 January 2026                [Page 14]

Internet-Draft             Use of HPKE in JOSE                 July 2025


   [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, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC7516]  Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
              RFC 7516, DOI 10.17487/RFC7516, May 2015,
              <https://www.rfc-editor.org/rfc/rfc7516>.

   [RFC7517]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
              DOI 10.17487/RFC7517, May 2015,
              <https://www.rfc-editor.org/rfc/rfc7517>.

   [RFC7518]  Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
              DOI 10.17487/RFC7518, May 2015,
              <https://www.rfc-editor.org/rfc/rfc7518>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC8725]  Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best
              Current Practices", BCP 225, RFC 8725,
              DOI 10.17487/RFC8725, February 2020,
              <https://www.rfc-editor.org/rfc/rfc8725>.

   [RFC9180]  Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid
              Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180,
              February 2022, <https://www.rfc-editor.org/rfc/rfc9180>.

11.2.  Informative References

   [I-D.ietf-cose-dilithium]
              Prorock, M. and O. Steele, "ML-DSA for JOSE and COSE",
              Work in Progress, Internet-Draft, draft-ietf-cose-
              dilithium-08, 7 July 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-cose-
              dilithium-08>.









Reddy, et al.            Expires 8 January 2026                [Page 15]

Internet-Draft             Use of HPKE in JOSE                 July 2025


   [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-15, 7 July 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-cose-
              hpke-15>.

   [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", April 2018,
              <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, June 2005,
              <https://www.rfc-editor.org/rfc/rfc4086>.

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 Matt Chanda, Ilari Liusvaara, Neil Madden, Aaron
   Parecki, Filip Skokan, and Sebastian Stenzel for their contributions
   to the specification.





Reddy, et al.            Expires 8 January 2026                [Page 16]

Internet-Draft             Use of HPKE in JOSE                 July 2025


Document History

   -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).





Reddy, et al.            Expires 8 January 2026                [Page 17]

Internet-Draft             Use of HPKE in JOSE                 July 2025


   *  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




Reddy, et al.            Expires 8 January 2026                [Page 18]

Internet-Draft             Use of HPKE in JOSE                 July 2025


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

Authors' Addresses

   Tirumaleswar Reddy
   Nokia
   Bangalore
   Karnataka
   India
   Email: kondtir@gmail.com


   Hannes Tschofenig
   University of Applied Sciences Bonn-Rhein-Sieg
   Germany
   Email: hannes.tschofenig@gmx.net


   Aritra Banerjee
   Nokia
   Munich
   Germany
   Email: aritra.banerjee@nokia.com


   Orie Steele
   Tradeverifyd
   United States
   Email: orie@or13.io


   Michael B. Jones
   Self-Issued Consulting
   United States
   Email: michael_b_jones@hotmail.com
   URI:   https://self-issued.info/














Reddy, et al.            Expires 8 January 2026                [Page 19]
