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]
