Summary

  • On 24 September 2026, the IESG approved draft-ietf-jose-hpke-encrypt-22 for publication as a Proposed Standard. It is still an Internet-Draft, not yet an RFC or evidence of deployment.
  • Integrated Encryption sends plaintext directly through HPKE to exactly one recipient. Key Encryption instead protects a shared content-encryption key and can place HPKE recipients beside ECDH or RSA recipients in one JWE JSON object.
  • The draft requires at least one recipient to validate, but leaves “one is enough” versus “all must succeed” to the application. It also states that a shared CEK is only as secure as its weakest recipient algorithm.

The green path that does not close the case

Imagine a JWE JSON object addressed to three operational roles: a production service, an escrow function and an incident-recovery service. The first recipient decrypts successfully. The library can recover the content-encryption key, validate the ciphertext and return plaintext. A dashboard can reasonably show a cryptographic success.

What has not yet been answered is whether the other two recipients were mandatory, optional or obsolete. A recovery key might be missing. An escrow path might have been wrapped with an algorithm the organisation has already forbidden. A recipient could have been added after the approved distribution list was signed off. The plaintext does not carry those organisational answers back out with it.

That distinction became timely on 24 September, when the IESG announced approval of revision 22 of the JOSE HPKE draft for publication as a Proposed Standard. The document gives JWE a carefully specified way to use HPKE. It does not claim that any product has shipped it, that an implementation matches the test vectors or that a particular recipient policy is correct. Until RFC publication, it also remains an Internet-Draft.

Two modes that create different records

The draft defines two JWE Key Management Modes, and their wire shapes should not be treated as cosmetic alternatives.

Integrated Encryption is the narrow path. HPKE encrypts the plaintext directly. There is no separate content-encryption key, so the enc header is forbidden. The protected alg header chooses a fully specified HPKE suite, ek is forbidden, and there must be exactly one recipient. The JWE Encrypted Key carries the HPKE encapsulated secret. The usual JWE initialisation-vector and authentication-tag slots are empty because those functions sit inside the integrated HPKE operation.

Key Encryption creates a second layer. JWE first protects the content under a randomly generated CEK and an enc algorithm. HPKE then encrypts that CEK for a recipient. The recipient’s JWE Encrypted Key is the HPKE ciphertext of the CEK, while ek carries the HPKE encapsulated secret. The Recipient_structure supplied to HPKE’s key schedule binds a JOSE-specific context string, the selected content-encryption algorithm and optional application context.

That indirection permits multiple recipients. In JWE JSON Serialization, an HPKE recipient can appear beside recipients using ECDH-ES+A128KW or RSA-OAEP-256. Each receives a different protected route to the same CEK; the content itself is encrypted once.

The advantage is practical. A migration can introduce HPKE without forcing every consumer to change on the same day. A regulated archive and a live service can use different recipient keys. A recovery function can be added without duplicating the entire ciphertext. But the same flexibility creates a policy surface that a single “decrypt succeeded” flag cannot describe.

The specification returns the missing distinction

Revision 22 makes the boundary explicit in its decryption procedure. With multiple recipients, the application decides which recipient entries must validate. Some contexts may require every recipient to succeed; others may accept one. At least one must succeed or the JWE is invalid.

For JWE JSON Serialization, the consumer is also instructed to return which recipient operations succeeded and which failed. That result is not diagnostic decoration. It is the input the application needs to apply the rule it owns.

Suppose recipient A opens under HPKE, recipient B fails because its key was rotated, and recipient C opens under a legacy algorithm. A library following the protocol can recover the plaintext. An application requiring only A has a valid outcome. An application requiring A and B does not. A policy that forbids C’s algorithm may reject the object even though C succeeded. The bytes are identical; the decision is not.

The draft reinforces this point by saying that successful decryption is insufficient when the algorithms used are unacceptable to the application. It does not encode a universal allow list because acceptability belongs to the deployment context. That is thin coordination done properly: the protocol exposes the facts needed for a local decision without pretending to supply the decision itself.

The weakest branch can govern the whole message

Key Encryption shares a CEK across the recipient set. Any recipient path that recovers it can decrypt the common ciphertext. The Security Considerations therefore state a blunt consequence: in a multi-recipient scenario, content security is limited by the weakest algorithm used to encrypt the CEK.

This is not a claim that mixed algorithms are always wrong. It is a claim about blast radius. A stronger HPKE path cannot make the CEK stronger than another accepted path through which the same key can be recovered. Migration policy must therefore assess the envelope as a set, not award the message the rating of its newest recipient.

Revision 22 itself offers a useful governance signal. After concerns in the standards process, a second Working Group Last Call reviewed removal of HPKE-4-KE and HPKE-6-KE. Those Key Encryption identifiers are absent from revision 22, while the corresponding Integrated Encryption identifiers remain. The difference is mode-specific; a controls inventory that records only “HPKE supported” would miss it.

The draft also advises against using one KEM key pair across multiple HPKE modes or suites, and against sharing a key between HPKE and non-HPKE algorithms. A recipient label is therefore not enough for an audit. The record needs the mode, suite, key identity and permitted purpose together.

Heng Lu’s distinction between symbolic and operational layers applies cleanly here. An approval notice is a standards-process fact. An alg identifier is a wire fact. A successful recipient entry is a cryptographic processing fact. The organisation’s distribution rule is a control fact. Only an observed application decision can say which rule was actually applied.

Sources