At the time of discussing adoption of draft-ietf-jose-pqc-kem I questioned the rational pursuing two different vehicles for PQ, https://mailarchive.ietf.org/arch/msg/jose/7jTHjvKTiSg41mGWmYZ3i_TBiAw/
Having two different paths forward for accommodating PQ(/T) seems less than ideal. As Filip said, we've invested considerably in refining the HPKE integration with JWE, and the emergent result provides a consistent container for both PQ and PQ/T algorithms. I'm supportive of the JOSE PQ(/T) work going in that proposed direction. Even (and perhaps better) if it doesn't go into a single document, the overall direction feels conceptually correct. On Tue, Dec 2, 2025 at 10:35 PM tirumal reddy <[email protected]> wrote: > 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] > -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
