I could live with dropping HPKE-4-KE and HPKE-6-KE for the consistency reason
Neil states. As I wrote in the thread about the IANA registrations with Filip
(the DE), Deb (the AD), and the authors, I believe that there is an appetite in
Europe and other jurisdictions for ChaCha options. HPKE-4 and HPKE-6 provide
them using HPKE Integrated Encryption, so I believe it’s appropriate to retain
them.
-- Mike
From: Neil Madden <[email protected]>
Sent: Wednesday, July 1, 2026 12:21 PM
To: Orie <[email protected]>
Cc: Brian Campbell <[email protected]>; [email protected]; The IESG
<[email protected]>; [email protected]; [email protected];
[email protected]; [email protected]; [email protected]
Subject: Re: [jose] Re: Last Call: <draft-ietf-jose-hpke-encrypt-17.txt> (Use
of Hybrid Public Key Encryption (HPKE) with JSON Web Encryption (JWE)) to
Proposed Standard
I agree with Brian that the HPKE-4-KE and HPKE-6-KE algorithms make little
sense without a ChaCha20-Poly1305 content encryption algorithm. Everything else
is largely a matter of taste.
On 1 Jul 2026, at 19:53, Orie <[email protected]<mailto:[email protected]>> wrote:
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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[email protected]> mailing lists by 2026-05-27.
Exceptionally, comments may
be sent to [email protected]<mailto:[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]<mailto:[email protected]>
To unsubscribe send an email to [email protected]<mailto:[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]<mailto:[email protected]>
To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________
jose mailing list -- [email protected]
To unsubscribe send an email to [email protected]
