In discussions at (and around) IETF 125 regarding the prospective JOSE HPKE PQ & PQ/T work, a very clear preference emerged among a rough consensus of the WG, its chairs, and its responsible AD for being thoughtful and intentional about the algorithm choices. This document, however, runs somewhat contrary to that ethos and includes a few rather questionable algorithms. Specifically, because JOSE does not have ChaCha20Poly1305 content encryption, the ChaCha20Poly1305 Key Encryption variants in this document are rather disjoint and borderline nonsensical. Why would one need to do HPKE with ChaCha20Poly1305 to encrypt a key that will be used for AES content encryption? If we as the standards creators don't have a compelling answer, we shouldn't burden implementers and the JOSE ecosystem with more unnecessary options. As such, I strongly suggest that HPKE-4-KE and HPKE-6-KE be removed from this draft. Honestly, I'd like to see the algorithm set pared down further but I can envision reasonable arguments for and against the others in the document, so I realize that doing so wouldn't be straightforward at all. However, I cannot see any justification for having HPKE-4-KE and HPKE-6-KE so removing those two seems like an easy win.
On Wed, May 13, 2026 at 2:23 PM The IESG <[email protected]> wrote: > > The IESG has received a request from the Javascript Object Signing and > Encryption WG (jose) to consider the following document: - 'Use of Hybrid > Public Key Encryption (HPKE) with JSON Web Encryption > (JWE)' > <draft-ietf-jose-hpke-encrypt-17.txt> as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > [email protected] mailing lists by 2026-05-27. Exceptionally, comments > may > be sent to [email protected] instead. In either case, please retain the > beginning > of the Subject line to allow automated sorting. > > Abstract > > > This specification defines how to use Hybrid Public Key Encryption > (HPKE) with JSON Web Encryption (JWE). HPKE enables public key > encryption of arbitrary-sized plaintexts to a recipient's public key, > and provides security against adaptive chosen ciphertext attacks. > This specification chooses a specific subset of the HPKE features to > use with JWE. > > This specification updates RFC 7516 (JWE) to enable use of Integrated > Encryption as a Key Management Mode. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-jose-hpke-encrypt/ > > > > No IPR declarations have been submitted directly on this I-D. > > > The document contains these normative downward references. > See RFC 3967 for additional information: > rfc8937: Randomness Improvements for Security Protocols (Informational > - Internet Research Task Force (IRTF) stream) > > > > > _______________________________________________ > 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]
