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. 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)
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?
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.
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.
|
