Use of Hybrid Public Key Encryption (HPKE) with JSON Web Encryption (JWE)

4.1. Encapsulated Secrets

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

When using Integrated Encryption, the JWE Encrypted Key of the sole recipient is the HPKE encapsulated secret.¶

When using Key Encryption, each recipient's JWE Encrypted Key is the encrypted content encryption key, and the value of header parameter "ek" is the base64url encoding of the HPKE encapsulated secret.¶

5.1. Integrated Encryption Algorithms using HPKE

The following JWE algorithms using HPKE are defined for use with the Integrated Encryption Key Establishment Mode:¶

+--------+----------------------------+-------------+------------------+
| "alg"  | HPKE KEM                   | HPKE KDF    | HPKE AEAD        |
+--------+----------------------------+-------------+------------------+
| HPKE-0 | DHKEM(P-256, HKDF-SHA256)  | HKDF-SHA256 | AES-128-GCM      |
| HPKE-1 | DHKEM(P-384, HKDF-SHA384)  | HKDF-SHA384 | AES-256-GCM      |
| HPKE-2 | DHKEM(P-521, HKDF-SHA512)  | HKDF-SHA512 | AES-256-GCM      |
| HPKE-3 | DHKEM(X25519, HKDF-SHA256) | HKDF-SHA256 | AES-128-GCM      |
| HPKE-4 | DHKEM(X25519, HKDF-SHA256) | HKDF-SHA256 | ChaCha20Poly1305 |
| HPKE-5 | DHKEM(X448, HKDF-SHA512)   | HKDF-SHA512 | AES-256-GCM      |
| HPKE-6 | DHKEM(X448, HKDF-SHA512)   | HKDF-SHA512 | ChaCha20Poly1305 |
| HPKE-7 | DHKEM(P-256, HKDF-SHA256)  | HKDF-SHA256 | AES-256-GCM      |
+--------+----------------------------+-------------+------------------+

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

5.2. JWE Compact Serialization Example

Below is an example of a JWE using the Compact Serialization and Integrated Encryption with HPKE:¶

eyJhbGciOiJIUEtFLTAiLCJraWQiOiJ5Q25mYm1ZTVpjV3JLRHRfRGpOZWJSQ0IxdnhWb3F2NHVtSjRXSzhSWWprIn0.BLAJX8adrFsDKaoJAc3iy2dq-6jEH3Uv-bSgqIoDeREqpWglMoTS67XsXere1ZYxiQKEFU6MbWe8O7vmdlSmcUk..NcN9ew5aijn8W7piLVRU8r2cOP0JKqxOF4RllVsJM4qsAfVXW5Ka6so9zdUmXXNOXyCEk0wV_s8ICAnD4LbRa5TkhTeuhijIfAt9bQ2fMLOeyed3WyArs8yaMraa9Zbh4i6SaHunM7jU_xoz_N2WbykSOSySmCO49H4mP3jLW9L_TYQfeVfYsrB8clqokZ8h-3eQGNwmOPtkjWdpAfaHUsp4-HC9nRd6yrTU6mV65Nn2iYynu3Xkgy2Lm-kQKDavIEW3PBpEeiw6mtPJE9o8sT-0lZ9kpWtqog2XbNGEfjSOjujvNe1b0g4-FdNFMFO_fo0rxe902W1pGT7znv4Q-xBkIydK4ZwjiFN6dAXutnococ37A0Hr5esPLwHRTTrBFw.

The key used for this example is in Appendix A.1.¶

5.3. Flattened JWE JSON Serialization Example

Below is an example of a JWE using the Flattened JSON Serialization and Integrated Encryption with HPKE:¶

{
  "ciphertext": "LabI8_KIPDbymUSbyVctj8AfISXQ07sMt1xQ1lrS-0heU2jjejpQIK75K1KXcvwn15E6Kil_tJ6LBcYCu02O1H8_aooJGuoLw1vEzQn16h498YX9e2SA2IcVrJTkcCjL7YpF9fsAF3JEzGfsmmrpZPPVdxCn7g8dkGRcyulnHrNvBu4BFtub-URtf-nYCFIJHZ4k-ul9fDddquicFzCxQonx66-ZX5nbj6azHG65tAZntd6VFkRgihdxTvIpvTS4gfulQeKyShbiw-OCJNbzFdEnOKEMnsyqRjwG7iVrFEilFAMsvLJ14-lcuR5btIkUntIwlnsfUa2Ytk33znCfAFN0wYukdDvJe-V0nnNUFlOeLyYV0eEGisgC9dQQ1kFu3g",
  "encrypted_key": "BAOlZ-VnbhQu4NOlTlDAVYwUJB-Q6YcWwnRNWK6YLSiHHlW4rN0qUzBJ3Rc2_y8nkasn8nUVGBzdq7OhdKKiLq4",
  "aad": "VGhlIEZlbGxvd3NoaXAgb2YgdGhlIFJpbmc",
  "protected": "eyJhbGciOiJIUEtFLTAiLCJraWQiOiJ5Q25mYm1ZTVpjV3JLRHRfRGpOZWJSQ0IxdnhWb3F2NHVtSjRXSzhSWWprIn0"
}

The key used for this example is in Appendix A.1.¶

6.1. Recipient_structure

The Recipient_structure used as the value of the HPKE info parameter when performing Key Encryption with HPKE 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:¶

• ASCII("JOSE-HPKE rcpt"): A fixed ASCII string identifying the context of the structure.¶

• BYTE(255): A separator byte (0xFF) used to delimit fields.¶

• ASCII(content_encryption_alg): Identifies the content encryption algorithm with which the HPKE-encrypted Content Encryption Key (CEK) is used. Its value MUST be the "enc" (encryption algorithm) header parameter value in the JOSE Header. This field provides JWE context information to the HPKE key schedule, which ensures that the encapsulated secret is bound to the selected content encryption algorithm.¶

• BYTE(255): A separator byte (0xFF) used to delimit fields.¶

• recipient_extra_info: An octet string containing additional context information that the application includes in the key derivation. Mutually known private information (a concept also utilized in [NIST.SP.800-56Ar3]) MAY be used in this input parameter. If no additional context information is provided, this field MUST be the empty octet sequence.¶

Note that Integrated Encryption does not use the Recipient_structure because the JWE Protected Header and JWE AAD are included in the HPKE aad value, which binds these parameters to the ciphertext.¶

"JOSE-HPKE rcpt\xffA128GCM\xff"

4a4f53452d48504b452072637074ff4131323847434dff

6.2. Key Encryption Algorithms using HPKE

The following JWE algorithms using HPKE are defined for use with the Key Encryption Key Establishment Mode:¶

+-----------+----------------------------+-------------+------------------+
| "alg"     | HPKE KEM                   | HPKE KDF    | HPKE AEAD        |
+-----------+----------------------------+-------------+------------------+
| HPKE-0-KE | DHKEM(P-256, HKDF-SHA256)  | HKDF-SHA256 | AES-128-GCM      |
| HPKE-1-KE | DHKEM(P-384, HKDF-SHA384)  | HKDF-SHA384 | AES-256-GCM      |
| HPKE-2-KE | DHKEM(P-521, HKDF-SHA512)  | HKDF-SHA512 | AES-256-GCM      |
| HPKE-3-KE | DHKEM(X25519, HKDF-SHA256) | HKDF-SHA256 | AES-128-GCM      |
| HPKE-4-KE | DHKEM(X25519, HKDF-SHA256) | HKDF-SHA256 | ChaCha20Poly1305 |
| HPKE-5-KE | DHKEM(X448, HKDF-SHA512)   | HKDF-SHA512 | AES-256-GCM      |
| HPKE-6-KE | DHKEM(X448, HKDF-SHA512)   | HKDF-SHA512 | ChaCha20Poly1305 |
| HPKE-7-KE | DHKEM(P-256, HKDF-SHA256)  | HKDF-SHA256 | AES-256-GCM      |
+-----------+----------------------------+-------------+------------------+

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

6.3. General JWE JSON Serialization Example

Below is an example of a JWE using the General JSON Serialization and Key Encryption with HPKE:¶

{
  "ciphertext": "uF1XBbVZWhYm_pDbeJvI_fkuqFJiKd1WMP3O_BAGOP-LkpTLE3Et2VQNcOpPAIBfyx8rUzshGqiOFOWzcoWZ3mIwYuDvvAW3-P1RCS8Dtq70JRvahO5O8sAN1vzJg8_dyBPnwsQY6Cy3RhMD6sSSCjjSw0FYmmx67IiI2zJ6Wr8z69k0f34ZTh43k4C-pTwaUSvjl2XI_YrUgdDVYmY_MJ5vmlPTcceMaefP8Onz_fx5xOcGfnVBVz2gpMQPuQL8k5Rk5KJvPGfFfN6hrgWkK_LDzi4lrfnIrvNsk3BCBeZPpc-n19-u7W4-GQxLjAlVyMHeGk5K4tU6gHB8PnnQ4ND5ZTtyXrJWQW-Qr1iFev6g",
  "iv": "mLiHjYaQA42nPm1L",
  "recipients": [
    {
      "encrypted_key": "hU6b0hp4-y4ZoK1Qz8YWmDmqDmgTto3HW25-RyPhcLU",
      "header": {
        "alg": "HPKE-0-KE",
        "kid": "9CfUPiGcAcTp7oXgVbDStw2FEjka-_KHU_i-X3XMCEA",
        "ek": "BGWPWLoD5BUjFEDIjMS-yvtcCXBn5A-kuv2RjzUY_2hKUjgZINqtEy1aHZ8dWxAiyApV5JafG76W8O_yZzy5T54"
      }
    }
  ],
  "tag": "K22C64ZhFABEu2S2F00PLg",
  "aad": "VGhlIEZlbGxvd3NoaXAgb2YgdGhlIFJpbmc",
  "protected": "eyJlbmMiOiJBMTI4R0NNIn0"
}

The key used for this example is in Appendix A.2.¶

7.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. (This is the algorithm recorded in the alg (algorithm) Header Parameter of the resulting JWE.)¶

2. When Key Wrapping, Key Encryption, or Key Agreement with Key Wrapping are employed, generate a random CEK value to use for subsequent steps unless one was already generated for a previously processed recipient, in which case, let that be the one used for subsequent steps. 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, 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. When Integrated Encryption is employed, let the JWE Encrypted Key be as specified by the Integrated Encryption algorithm.¶

8. Compute the encoded key value BASE64URL(JWE Encrypted Key).¶

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

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

11. Compute the encoded Initialization Vector value BASE64URL(JWE Initialization Vector).¶

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

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

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. If Integrated Encryption is not being employed, 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).¶

17. If Integrated Encryption is being employed, encrypt M using the specified Integrated Encryption algorithm to create the JWE Ciphertext value. Let the JWE Authentication Tag be the empty octet sequence.¶

18. Compute the encoded ciphertext value BASE64URL(JWE Ciphertext).¶

19. Compute the encoded Authentication Tag value BASE64URL(JWE Authentication Tag).¶

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

21. 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].¶

7.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 algorithm specified by the alg (algorithm) Header Parameter.¶

7. If using Integrated Encryption, Direct Encryption or Direct Key Agreement, verify that there is exactly one recipient.¶

8. Verify that the JWE uses a key known to the recipient.¶

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

10. When Key Wrapping, 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.¶

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

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

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

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

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

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

17. If Integrated Encryption is not being employed, 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 content encryption algorithm specified in the "enc" header parameter, 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.¶

18. If Integrated Encryption is being employed, verify that no "enc" header parameter is present.¶

19. If Integrated Encryption is being employed, decrypt the JWE Ciphertext using the specified Integrated Encryption algorithm, returning the decrypted plaintext in the manner specified for the algorithm, rejecting the input without emitting any decrypted output if the decryption fails.¶

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

21. 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.1. JWK Representation of Key using JWE HPKE Ciphersuite

The example below is a JWK representation of a public and private key used with the Integrated Encryption Key Establishment Mode:¶

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

10.1. Key Management

A single key MUST NOT be used with multiple KEM algorithms. Each key and its associated HPKE 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. JWT Best Current Practices

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

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

11.2. JSON Web Signature and Encryption Header Parameters

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

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, 4 November 2025, <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, 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>.

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

[RFC8259]

Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <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, February 2020, <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, 19 October 2025, <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", 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>.

[RFC7515]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/rfc/rfc7515>.

[RFC7518]

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

[RFC9864]

Jones, M.B. and O. Steele, "Fully-Specified Algorithms for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE)", RFC 9864, DOI 10.17487/RFC9864, October 2025, <https://www.rfc-editor.org/rfc/rfc9864>.

A.1. Integrated Encryption Key

This private key and its implied public key are used for the Integrated Encryption example in Section 5.2 and Section 5.3:¶

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

A.2. Key Encryption Key

This private key and its implied public key are used for the Key Encryption example in Section 6.3:¶

{
  "kty": "EC",
  "use": "enc",
  "alg": "HPKE-0-KE",
  "kid": "9CfUPiGcAcTp7oXgVbDStw2FEjka-_KHU_i-X3XMCEA",
  "crv": "P-256",
  "x": "WVKOswXQAgntIrLSYlwkyaU1dIE-FIhrbTEotFgMwIA",
  "y": "jpZT1WNmQH752Bh_pDK41IhLkiXLj-15wR4ZBZ-MWFk",
  "d": "MeCnMF65SaRVZ11Gf1Weacx3H9SdzO7MtWcDXvHWNv8"
}