Hey Brian, I drafted a reply to you but failed to send it. I'm supportive of the perspective to pare down algorithms, but I would want to hear from the WG on which ones should be removed.
Regards, OS (just one author, without discussing with the others) On Wed, Jul 1, 2026 at 1:05 PM Brian Campbell <[email protected]> wrote: > The last call comments below, which I belive to be substantive and > reasonable, were sent well within the last call period for draft-ietf-jose- > hpke-encrypt. > > No justification or rationale for including the algorithms was received > from the authors or WG. No response or even acknowledgement was received > from the authors. > > Yet it appears the document has moved to IESG evaluation. > > I'm not even sure what to say at this point but will try to > be constructive and ask: was there an oversight here? > > > > > > > On Mon, May 18, 2026 at 6:43 AM Brian Campbell <[email protected]> > wrote: > >> 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]
