I would oppose expanding draft-ietf-jose-hpke-encrypt in this direction. The scope of that draft is intentionally narrow. It was previously discussed and agreed that PQ/T Hybrid work would be handled separately, and the HPKE WG is taking the same approach. The need for draft-ietf-jose-pqc-kem was already discussed at the time of its adoption, providing a clean, HPKE-independent path for deployments that want to migrate to PQC-only KEMs.
Cheers, -Tiru On Tue, 2 Dec 2025 at 15:26, Filip Skokan <[email protected]> wrote: > Dear JOSE WG and draft-ietf-jose-hpke-encrypt authors, > > I'd like to propose that we consider using draft-ietf-jose-hpke-encrypt as > the vehicle for adding Post-Quantum (PQ) and Post-Quantum/Traditional > hybrid (PQ/T) key encapsulation support to JOSE, rather than continuing > with draft-ietf-jose-pqc-kem. > > We've spent considerable time refining the HPKE integration with JWE, and > the architecture that has emerged provides a clean mapping for both PQ and > PQ/T Hybrid algorithms. > > *Key Management Mode Alignment* > > - JWE HPKE's Integrated Encryption fills the role of what > draft-ietf-jose-pqc-kem calls "Direct Key Agreement", single recipient > - JWE HPKE's Key Encryption mode fills the role of what > draft-ietf-jose-pqc-kem calls "Key Wrapping", multiple recipients > > This clear separation in draft-ietf-jose-hpke-encrypt makes it > straightforward to add PQ and PQ/T algorithms to the JWE suite without > introducing a separate document and its definition of yet another key > derivation. > > *Simple Key Representation* > > For PQ and PQ/T HPKE, the JWK representation uses the "AKP" key type with: > > - pub: base64url encoding of HPKE's SerializePublicKey output > - priv: base64url encoding of HPKE's SerializePrivateKey output > > This is consistent with how draft-ietf-hpke-pq defines key serialization > and results in the exact same representation as the one decided for > draft-ietf-jose-pqc-kem for its Pure PQ KEMs. > > *Proof of Concept:* > > I've opened a draft PR > <https://github.com/ietf-wg-jose/draft-ietf-jose-hpke-encrypt/pull/91> for > the purposes of demonstrating this approach by adding two example > algorithms: > > - PQ: HPKE-8 / HPKE-8-KE: ML-KEM-768, HKDF-SHA256, AES-128-GCM > - PQ/T Hybrid: HPKE-9 / HPKE-9-KE: MLKEM768-X25519, HKDF-SHA256, > AES-128-GCM > > These two HPKE ciphersuites are illustrative, they show how > straightforward the integration is and demonstrate the key representation. > They are not intended to be the only PQ/PQT algorithms we'd add. > > *Benefits of this approach:* > > - Reuses the HPKE framework rather than defining new mechanisms > - Leverages draft-ietf-hpke-pq directly for KEM definitions > - Consistent key representation across PQ and PQ/T algorithms > - Simpler specification, no need for separate PQ-specific documents > - Faster time to market for PQ/T and (I believe) PQ than going through > separate HPKE and draft-ietf-jose-pqc-kem last calls and everything that > follows. > > As seen in the PR > <https://github.com/ietf-wg-jose/draft-ietf-jose-hpke-encrypt/pull/91> this > is very simple to do. > > I believe consolidating our PQ efforts into draft-ietf-jose-hpke-encrypt > will result in a cleaner state of affairs and considerably reduce the > complexity for implementers. Speaking as one of those implementers I would > much prefer to just do draft-ietf-jose-hpke-encrypt incl. PQ than having to > separately deal with draft-ietf-jose-hpke-encrypt, draft-ietf-jose-pqc-kem, > and whichever other document that would bring PQ/T Hybrids. > > Thoughts? > > *i'm including COSE WG in CC as well as the draft-ietf-jose-hpke-encrypt > authors have shown continued interest in keeping the two in lockstep* > > S pozdravem, > *Filip Skokan* >
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
