Use of Hybrid Public Key Encryption (HPKE) with JSON Object Signing and Encryption (JOSE)
draft-ietf-jose-hpke-encrypt-07
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Tirumaleswar Reddy.K , Hannes Tschofenig , Aritra Banerjee , Orie Steele , Michael B. Jones | ||
| Last updated | 2025-03-18 (Latest revision 2025-02-28) | ||
| Replaces | draft-rha-jose-hpke-encrypt | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-jose-hpke-encrypt-07
JOSE T. Reddy
Internet-Draft Nokia
Intended status: Standards Track H. Tschofenig
Expires: 19 September 2025 H-BRS
A. Banerjee
Nokia
O. Steele
Transmute
M. Jones
Self-Issued Consulting
18 March 2025
Use of Hybrid Public Key Encryption (HPKE) with JSON Object Signing and
Encryption (JOSE)
draft-ietf-jose-hpke-encrypt-07
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 works for any combination of an asymmetric key encapsulation
mechanism (KEM), key derivation function (KDF), and authenticated
encryption with additional data (AEAD) function. Authentication for
HPKE in JOSE is provided by JOSE-native security mechanisms or by one
of the authenticated variants of HPKE.
This document defines the use of the HPKE with JOSE.
About This Document
This note is to be removed before publishing as an RFC.
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/.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Reddy, et al. Expires 19 September 2025 [Page 1]
Internet-Draft Use of HPKE in JOSE March 2025
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 19 September 2025.
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
5.2. JSON Example . . . . . . . . . . . . . . . . . . . . . . 7
6. Key Encryption . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Multiple Recipients Example . . . . . . . . . . . . . . . 8
7. Mapping HPKE Keys to JWK for JOSE . . . . . . . . . . . . . . 10
7.1. JWK Representation of a JOSE-HPKE Key with HPKE
Ciphersuite . . . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8.1. Authentication using an Asymmetric Key . . . . . . . . . 11
8.2. Key Management . . . . . . . . . . . . . . . . . . . . . 12
8.3. Plaintext Compression . . . . . . . . . . . . . . . . . . 12
8.4. Header Parameters . . . . . . . . . . . . . . . . . . . . 12
8.5. Ensure Cryptographic Keys Have Sufficient Entropy . . . . 12
Reddy, et al. Expires 19 September 2025 [Page 2]
Internet-Draft Use of HPKE in JOSE March 2025
8.6. Validate Cryptographic Inputs . . . . . . . . . . . . . . 12
8.7. Use Appropriate Algorithms . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9.1. Ciphersuite Registration . . . . . . . . . . . . . . . . 13
9.2. JSON Web Signature and Encryption Algorithms . . . . . . 14
9.2.1. HPKE-0 . . . . . . . . . . . . . . . . . . . . . . . 14
9.2.2. HPKE-1 . . . . . . . . . . . . . . . . . . . . . . . 14
9.2.3. HPKE-2 . . . . . . . . . . . . . . . . . . . . . . . 14
9.2.4. HPKE-3 . . . . . . . . . . . . . . . . . . . . . . . 15
9.2.5. HPKE-4 . . . . . . . . . . . . . . . . . . . . . . . 15
9.2.6. HPKE-5 . . . . . . . . . . . . . . . . . . . . . . . 16
9.2.7. HPKE-6 . . . . . . . . . . . . . . . . . . . . . . . 16
9.3. JSON Web Signature and Encryption Header Parameters . . . 16
9.3.1. ek . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.3.2. psk_id . . . . . . . . . . . . . . . . . . . . . . . 17
9.3.3. auth_kid . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Keys Used in Examples . . . . . . . . . . . . . . . 18
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19
Document History . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
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 19 September 2025 [Page 3]
Internet-Draft Use of HPKE in JOSE March 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 describes 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 "dir", HPKE JWE Integrated Encryption is used.
* If "enc" is an AEAD algorithm, the recipient Key Managment 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, the HPKE mode used (e.g, "mode_base" or
"mode_auth_psk") is determined by the presence of the JOSE Header
parameters "psk_id" and "auth_kid".
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 19 September 2025 [Page 4]
Internet-Draft Use of HPKE in JOSE March 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 }.
4.1. Auxiliary Authenticated Application Information
HPKE has two places at which applications can specify auxiliary
authenticated information as described in { Section 8.1 of RFC9180 }.
HPKE algorithms are not required to process "apu" and "apv" as
described in Section 4.6.1 of [RFC7518], despite appearing to be
similar to key agreement algorithms (such as "ECDH-ES").
The "aad parameter" for Open() and Seal() MUST be used with both HPKE
JWE Integrated Encryption and HPKE JWE Key Encryption.
To avoid confusion between JWE AAD and HPKE AAD, this document uses
the term "HPKE AEAD AAD" to refer the "aad parameter" for Open() and
Seal().
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 19 September 2025 [Page 5]
Internet-Draft Use of HPKE in JOSE March 2025
* The protected header MUST contain an "alg" that is JOSE-HPKE
algorithm.
* The protected header MUST contain an "enc" with value "dir". 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" and "auth_kid" 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].
* JWE Initialization Vector and JWE Authentication Tag MUST NOT be
present.
* JWE AAD MAY be present.
* JWE Ciphertext is ciphertext as defined in Section 5.2 of
[RFC9180].
* The HPKE info parameter MUST be set to an empty string.
* The HPKE aad parameter MUST be set to the "JWE Additional
Authenticated Data encryption parameter", as defined in Step 14 of
Section 5.1 of [RFC7516].
* If protected header contains the parameter "zip" (Section 4.1.3 of
[RFC7516]), the plaintext is the message compressed with the
indicated algorithm. Otherwise, the plaintext is the raw message.
When decrypting, the checks in [RFC7516] section 5.2, steps 1 through
5 MUST be performed. The JWE Encrypted Key in step 2 is the
base64url encoded encapsulated key.
5.1. Compact Example
A Compact JWE or JSON Web Token:
eyJhbGciOiJIUEtFLVAyNTYtU0hBMjU2LUExMjhHQ00iLCJlbmMiOiJkaXIiLCJraWQiOiJ1cm46aWV0ZjpwYXJhbXM6b2F1dGg6andrLXRodW1icHJpbnQ6c2hhLTI1Njp2b2RIQ3FjVVdFbV83NUpWcXlhTjhaS1FVMjF3VEFSYzhkRzhuVU1jZlBVIn0.BCsvYxTHM4CO_OwQxL3lkJDdlw3UDjx2xN9MIXnbVzfTgFJmo_Es2xdH-fYs9EXfH_V53JgMWfUm7rBD_oE5efU..7_va6cnwClMsw7h7lqpm2tCrH9NkciM-g9UabdPWcOeIRmAf01NLYG7Wn8fFoohHlcGgd0nh7Jmo9nvHFi7sH6kOX7pplBnvLUoPrqeyW4TdXo_X8YThNKf9BFyWGyF6fjelbic5jSYClFaenMkTnjpHxFW1sWuiuZVmO1EOzrlNttWy.
After verification:
Reddy, et al. Expires 19 September 2025 [Page 6]
Internet-Draft Use of HPKE in JOSE March 2025
{
"protectedHeader": {
"alg": "HPKE-0",
"enc": "dir",
"kid": "urn:ietf:params:oauth:jwk-thumbprint:sha-256:vodHCqcUWEm_75JVqyaN8ZKQU21wTARc8dG8nUMcfPU"
},
"payload": {
"urn:example:claim": true,
"iss": "urn:example:issuer",
"aud": "urn:example:audience",
"iat": 1729785491,
"exp": 1729792691
}
}
5.2. JSON Example
A JSON Encoded JWE:
{
"protected": "eyJhbGciOiJIUEtFLVAyNTYtU0hBMjU2LUExMjhHQ00iLCJlbmMiOiJkaXIiLCJraWQiOiJ1cm46aWV0ZjpwYXJhbXM6b2F1dGg6andrLXRodW1icHJpbnQ6c2hhLTI1NjpTNkFYZmRVXzZZZnp2dTBLRERKYjBzRnV3bklXUGs2TE1URXJZaFBiMzJzIiwicHNrX2lkIjoib3VyLXByZS1zaGFyZWQta2V5LWlkIiwiYXV0aF9raWQiOiJ1cm46aWV0ZjpwYXJhbXM6b2F1dGg6andrLXRodW1icHJpbnQ6c2hhLTI1NjpTNkFYZmRVXzZZZnp2dTBLRERKYjBzRnV3bklXUGs2TE1URXJZaFBiMzJzIn0",
"encrypted_key": "BD7QVodtG-FwYASgb36zuTzUCc80aiYwS6JOOE-6_heUGyAZt-cU0818e4oYqP7ebBuW3KTM9EQA0vM5fWp6hj0",
"ciphertext": "ZxqtYoomgVQGctnv1I_EBVI1NIeJ7qJw2iVtqwUw3fXa8FK-",
"aad": "8J-PtOKAjeKYoO-4jyBiZXdhcmUgdGhlIGFhZCE"
}
After verification:
{
"protectedHeader": {
"alg": "HPKE-0",
"enc": "dir",
"kid": "urn:ietf:params:oauth:jwk-thumbprint:sha-256:S6AXfdU_6Yfzvu0KDDJb0sFuwnIWPk6LMTErYhPb32s",
"psk_id": "our-pre-shared-key-id",
"auth_kid": "urn:ietf:params:oauth:jwk-thumbprint:sha-256:S6AXfdU_6Yfzvu0KDDJb0sFuwnIWPk6LMTErYhPb32s"
},
"plaintext": "🖤 this plaintext!",
"additionalAuthenticatedData": "🏴☠️ beware the aad!"
}
6. Key Encryption
Recipients using JOSE-HPKE can be added alongside other recpients
(e.g., ECDH-ES+A128KW or RSA-OAEP-384), as HPKE is used to encrypt
the Content Encryption Key, which is then processed as specified in
JWE.
Reddy, et al. Expires 19 September 2025 [Page 7]
Internet-Draft Use of HPKE in JOSE March 2025
The protected header used in content encryption is passed to HPKE as
Additional Authenticated Data. The protected header encoding remains
consistent with existing JWE formatting 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 "auth_kid" SHOULD NOT be present.
* JOSE Header parameter "ek" MUST be present and contain base64url-
encoded HPKE encapsulated key.
* Recipient JWE Encrypted Key MUST be the ciphertext from HPKE
Encryption.
* The HPKE Setup info parameter MUST be set to an empty string.
* THE HPKE plaintext MUST be set to the CEK.
The processing of "enc", "iv", "tag", "aad", and "ciphertext" is
already defined in [RFC7516]. Implementations should follow the
existing JWE specifications for handling these parameters, and no
additional processing requirements are introduced by HPKE-based key
encryption.
6.1. Multiple Recipients Example
For example:
Reddy, et al. Expires 19 September 2025 [Page 8]
Internet-Draft Use of HPKE in JOSE March 2025
{
"protected": "eyJlbmMiOiJBMTI4R0NNIn0",
"iv": "ZL0HDvZJizA6vyTV",
"ciphertext": "Oq26x9vppULrGNzCn2jaB_Sl-Swjv7e0AcgnhUR5AtrjEf2v6jee09WN-Ne-HIGXBgQpgJPchg0eWNmgv4Ozi5I",
"tag": "ULnlOiJRYfCzM_r5j9sLEQ",
"aad": "cGF1bCBhdHJlaWRlcw",
"recipients": [
{
"encrypted_key": "G3HmlpOgA4H1i_RQhT44Nw7svDwUqvNR",
"header": {
"kid": "urn:ietf:params:oauth:jwk-thumbprint:sha-256:cxQC_lWt22BIjH5AWSLHCZk_f-mU3-W4Ztcu5-ZbwTk",
"alg": "ECDH-ES+A128KW",
"epk": {
"kty": "EC",
"crv": "P-256",
"x": "JnGWSQ90hlt0H7bfcgfaw2DZE-qqv_cwA4_Dn_CkLzE",
"y": "6jw1AC5q9-qewwBh9DK5YzUHLOogToGDSpoYAJdNo-E"
}
}
},
{
"encrypted_key": "pn6ED0ijngCiWF8Hd_PzTyayd2OmRF7QarTVfuWj6dw",
"header": {
"alg": "HPKE-0",
"kid": "urn:ietf:params:oauth:jwk-thumbprint:sha-256:S6AXfdU_6Yfzvu0KDDJb0sFuwnIWPk6LMTErYhPb32s",
"psk_id": "our-pre-shared-key-id",
"auth_kid": "urn:ietf:params:oauth:jwk-thumbprint:sha-256:S6AXfdU_6Yfzvu0KDDJb0sFuwnIWPk6LMTErYhPb32s",
"ek": "BI41YDnhTTI6jSd7T62rLwzCCt_tBqN5LFooiZ7eXJsh01O0-h-BQ6JToKX9UXDw_3ylbXTiYWmPXl2fNmr4BeQ"
}
}
]
}
After verification:
Reddy, et al. Expires 19 September 2025 [Page 9]
Internet-Draft Use of HPKE in JOSE March 2025
{
"plaintext": "🎵 My lungs taste the air of Time Blown past falling sands 🎵",
"protectedHeader": {
"enc": "A128GCM"
},
"unprotectedHeader": {
"alg": "HPKE-0",
"enc": "dir",
"kid": "urn:ietf:params:oauth:jwk-thumbprint:sha-256:S6AXfdU_6Yfzvu0KDDJb0sFuwnIWPk6LMTErYhPb32s",
"psk_id": "our-pre-shared-key-id",
"auth_kid": "urn:ietf:params:oauth:jwk-thumbprint:sha-256:S6AXfdU_6Yfzvu0KDDJb0sFuwnIWPk6LMTErYhPb32s",
"ek": "BI41YDnhTTI6jSd7T62rLwzCCt_tBqN5LFooiZ7eXJsh01O0-h-BQ6JToKX9UXDw_3ylbXTiYWmPXl2fNmr4BeQ"
},
"additionalAuthenticatedData": "paul atreides"
}
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 |
+---------------------+-----+-----------+
Figure 1: JWK Types and Curves for JOSE-HPKE Ciphersuites
When the "kty" field is "AKP" 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
An example is illustrated below for representing a JOSE-HPKE public/
private keys.
Reddy, et al. Expires 19 September 2025 [Page 10]
Internet-Draft Use of HPKE in JOSE March 2025
{
"kty": "OKP",
"crv": "X25519",
"x": "3pPHgcHYVYpOpB6ISwHdoPRB6jNgd8mM4nRyyj4H3aE",
"d": "nWGxne0tAiV8Hk6kcy4rN0wMskjl9yND0N3Xeho9n6g",
"kid": "recipient-key-1",
"alg": "HPKE-3",
"key_ops": "encrypt"
}
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. 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 [RFC8937] for
random number generations are followed.
8.1. Authentication using an Asymmetric Key
Implementers are cautioned to note that the use of authenticated KEMs
has different meaning when considering integrated encryption and key
encryption. In integrated encryption the KEM operations secure the
message plaintext, whereas with key encryption, the KEM operations
secure the content encryption key. For this reason, the use of
authenticated KEMs with key encryption is NOT RECOMMENDED, as it
gives a false sense of security. See RFC9180 Section 5.1.3 for
details authentication using asymmetric keys.
Reddy, et al. Expires 19 September 2025 [Page 11]
Internet-Draft Use of HPKE in JOSE March 2025
8.2. Key Management
A single KEM key MUST 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 suites, ensuring
the integrity and security guarantees of each algorithm suite are
preserved. Additionally, the same key MUST 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.
A single recipient or sender key MUST NOT be used with both JOSE-HPKE
and other algorithms as this might enable cross-protocol attacks.
8.3. Plaintext Compression
Implementers are advised to review Section 3.6 of [RFC8725], which
states: Compression of data SHOULD NOT be done before encryption,
because such compressed data often reveals information about the
plaintext.
8.4. Header Parameters
Implementers are advised to review Section 3.10 of [RFC8725], which
comments on application processing of JWE Protected Headers.
Additionally, Unprotected Headers can contain similar information
which an attacker could leverage to mount denial of service, forgery
or injection attacks.
8.5. Ensure Cryptographic Keys Have Sufficient Entropy
Implementers are advised to review Section 3.5 of [RFC8725], which
provides comments on entropy requirements for keys. This guidance is
relevant to both public and private keys used in both Key Encryption
and Integrated Encryption. Additionally, this guidance is applicable
to content encryption keys used in Key Encryption mode.
8.6. Validate Cryptographic Inputs
Implementers are advised to review Section 3.4 of [RFC8725], which
provides comments on the validation of cryptographic inputs. This
guidance is relevant to both public and private keys used in both Key
Encryption and Integrated Encryption, specifically focusing on the
structure of the public and private keys. These inputs are crucial
for the HPKE KEM operations.
Reddy, et al. Expires 19 September 2025 [Page 12]
Internet-Draft Use of HPKE in JOSE March 2025
8.7. Use Appropriate Algorithms
Implementers are advised to review Section 3.2 of [RFC8725], which
comments on the selection of appropriate algorithms. This is
guidance is relevant to both Key Encryption and Integrated
Encryption. When using Key Encryption, the strength of the content
encryption algorithm should not be significantly different from the
strengh of the Key Encryption algorithms used.
9. IANA Considerations
This document adds entries to [JOSE-IANA].
9.1. 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, is composed of the following choices:
* KEM Algorithm
* KDF Algorithm
* AEAD Algorithm
The "KEM", "KDF", and "AEAD" values are chosen from the HPKE IANA
registry [HPKE-IANA].
The "HPKE Mode" is described in Table 1 of [RFC9180]:
* "Base" refers to "mode_base" described in Section 5.1.1 of
[RFC9180], 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
[RFC9180], which authenticates using a pre-shared key.
* "Auth" refers to "mode_auth", described in Section 5.1.3 of
[RFC9180], which authenticates using an asymmetric key.
* "Auth_Psk" refers to "mode_auth_psk", described in Section 5.1.4
of [RFC9180], which authenticates using both a PSK and an
asymmetric key.
The mode used is specified by presence or absence of header
parameters "psk_id" and "auth_kid".
Reddy, et al. Expires 19 September 2025 [Page 13]
Internet-Draft Use of HPKE in JOSE March 2025
9.2. JSON Web Signature and Encryption Algorithms
The following entries are added to the "JSON Web Signature and
Encryption Algorithms" registry:
9.2.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): RFCXXXX
* Algorithm Analysis Documents(s): TODO
9.2.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): RFCXXXX
* Algorithm Analysis Documents(s): TODO
9.2.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.
Reddy, et al. Expires 19 September 2025 [Page 14]
Internet-Draft Use of HPKE in JOSE March 2025
* Algorithm Usage Location(s): "alg"
* JOSE Implementation Requirements: Optional
* Change Controller: IETF
* Specification Document(s): RFCXXXX
* Algorithm Analysis Documents(s): TODO
9.2.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): RFCXXXX
* Algorithm Analysis Documents(s): TODO
9.2.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, enc"
* JOSE Implementation Requirements: Optional
* Change Controller: IETF
* Specification Document(s): RFCXXXX
* Algorithm Analysis Documents(s): TODO
Reddy, et al. Expires 19 September 2025 [Page 15]
Internet-Draft Use of HPKE in JOSE March 2025
9.2.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): RFCXXXX
* Algorithm Analysis Documents(s): TODO
9.2.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): RFCXXXX
* Algorithm Analysis Documents(s): TODO
9.3. JSON Web Signature and Encryption Header Parameters
The following entries are added to the "JSON Web Key Parameters"
registry:
9.3.1. ek
* Header Parameter Name: "ek"
* Header Parameter Description: An encapsulated key as defined in {
Section 5.1.1 of RFC9180 }
Reddy, et al. Expires 19 September 2025 [Page 16]
Internet-Draft Use of HPKE in JOSE March 2025
* Header Parameter Usage Location(s): JWE
* Change Controller: IETF
* Specification Document(s): RFCXXXX
9.3.2. psk_id
* Header Parameter Name: "psk_id"
* Header Parameter Description: A 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): RFCXXXX
9.3.3. auth_kid
* Header Parameter Name: "auth_kid"
* Header Parameter Description: A key identifier (kid) for the
asymmetric key as defined in { Section 5.1.3 of RFC9180 }
* Header Parameter Usage Location(s): JWE
* Change Controller: IETF
* Specification Document(s): RFCXXXX
10. References
10.1. Normative References
[JOSE-IANA]
IANA, "JSON Web Signature and Encryption Algorithms",
n.d., <https://www.iana.org/assignments/jose/jose.xhtml>.
[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>.
Reddy, et al. Expires 19 September 2025 [Page 17]
Internet-Draft Use of HPKE in JOSE March 2025
[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>.
10.2. Informative References
[HPKE-IANA]
IANA, "Hybrid Public Key Encryption (HPKE) IANA Registry",
October 2023,
<https://www.iana.org/assignments/hpke/hpke.xhtml>.
[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-11, 2 March 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-cose-
hpke-11>.
[RFC8937] Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N.,
and C. Wood, "Randomness Improvements for Security
Protocols", RFC 8937, DOI 10.17487/RFC8937, October 2020,
<https://www.rfc-editor.org/rfc/rfc8937>.
Appendix A. Keys Used in Examples
This private key and its implied public key are used the examples:
Reddy, et al. Expires 19 September 2025 [Page 18]
Internet-Draft Use of HPKE in JOSE March 2025
{
"kid": "S6AXfdU_6Yfzvu0KDDJb0sFuwnIWPk6LMTErYhPb32s",
"alg": "HPKE-0",
"kty": "EC",
"crv": "P-256",
"x": "wt36K06T4T4APWfGtioqDBXCvRN9evqkZjNydib9MaM",
"y": "eupgedeE_HAmVJ62kpSt2_EOoXb6e0y2YF1JPlfr1-I",
"d": "O3KznUTAxw-ov-9ZokwNaJ289RgP9VxQc7GJthaXzWY"
}
This pre-shared key is used in the examples:
{
"kty": "oct",
"kid": "our-pre-shared-key-id",
"k": "anVnZW11anVnZW11Z29rb3Vub3N1cmlraXJla2FpamE"
}
Acknowledgments
This specification leverages text from [I-D.ietf-cose-hpke]. We
would like to thank Matt Chanda, Ilari Liusvaara, Aaron Parecki, and
Filip Skokan for their contributions to the specification.
Document History
-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 Recipeint context.
* Added new Section 7.1 (Authentication using an Asymmetric Key).
* Updated Section 7.2 (Key Management) to prevent cross-protocol
attacks.
* Updated HPKE Setup info parameter to be empty.
* Added details on HPKE AEAD AAD, compression and decryption for
HPKE Integrated Encryption.
-04
Reddy, et al. Expires 19 September 2025 [Page 19]
Internet-Draft Use of HPKE in JOSE March 2025
* Fixed #8: Use short algorithm identifiers, per the JOSE naming
conventions.
-03
* Added new section 7.1 to discuss Key Management.
* HPKE Setup info parameter is updated to carry JOSE context-
specific data for both modes.
-02
* Fixed #4: HPKE Integrated Encryption "enc: dir".
* Updated text on the use of HPKE Setup info parameter.
* Added Examples in Sections 5.1, 5.2 and 6.1.
* Use of registered HPKE "alg" value in the recipient unprotected
header for Key Encryption.
-01
* Apply feedback from call for adoption.
* Provide examples of auth and psk modes for JSON and Compact
Serializations
* Simplify description of HPKE modes
* Adjust IANA registration requests
* Remove HPKE Mode from named algorithms
* Fix AEAD named algorithms
-00
* Created initial working group version from draft-rha-jose-hpke-
encrypt-07
Authors' Addresses
Tirumaleswar Reddy
Nokia
Bangalore
Karnataka
India
Reddy, et al. Expires 19 September 2025 [Page 20]
Internet-Draft Use of HPKE in JOSE March 2025
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
Transmute
United States
Email: orie@transmute.industries
Michael B. Jones
Self-Issued Consulting
United States
Email: michael_b_jones@hotmail.com
URI: https://self-issued.info/
Reddy, et al. Expires 19 September 2025 [Page 21]