Hi, I'm supportive of not giving JOSE / COSE implementers 2 PQ migration strategies to consider.
The original reason I started working on HPKE in JOSE and COSE was that I saw HPKE was adding support for hybrids, and it seemed like a single interface for PQ migration for both JOSE and COSE, with support for hybrid and pure pq could be possible. This had the potential to simplify things, while improving the baseline security by delegating responsibility to HPKE. The design goals I had in mind were (still are): - Crypto libraries that power JOSE, should be able to power COSE. - Algorithms and Key Formats should be aligned between JOSE and COSE for PQC. - The same PQ and PQ/T options should be available for both. - Minimal changes to both JOSE and COSE to support KEMs, where changes are required, have them be consistent. In short, I hope we could modernize both JOSE and COSE while deferring significant cryptographic responsibility to HPKE. I'm supportive of doing that, and I would prefer if there was not a similar but slightly different way of doing PQ, that would require different security analysis, and lead to different classes of attack. Regards, OS On Tue, Dec 2, 2025 at 3:56 AM 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]
