[Openid-dcp] ChaCha20Poly1305 algorithms and JOSE HPKE

[Michael Jones]

Hi DCP working group,

The JOSE HPKE spec<https://www.ietf.org/archive/id/draft-ietf-jose-hpke-encrypt-17.html> currently has four algorithms that use ChaCha20Poly1305 as the HPKE AEAD algorithm.  Publication of the spec was requested, meaning it is no longer in the JOSE working group.  It is currently in IETF last call.  The question is being asked whether to keep the algorithm registrations using ChaCha20Poly1305 or to discard them.

For those in the DCP working group who have use cases for HPKE, I’m curious whether you intend to use the ChaCha20Poly1305 algorithms or not.  Anecdotally, I’ve heard that there’s an affinity for those algorithms in some German contexts, for instance.

Do any of you want to weigh in on this topic?

                                                                -- Mike

From: Brian Campbell <bcampbell at pingidentity.com>
Sent: Monday, May 18, 2026 2:43 PM
To: last-call at ietf.org
Cc: debcooley1 at gmail.com; draft-ietf-jose-hpke-encrypt at ietf.org; jose-chairs at ietf.org; jose at ietf.org; michael.p1 at ncsc.gov.uk
Subject: Re: [jose] Last Call: <draft-ietf-jose-hpke-encrypt-17.txt> (Use of Hybrid Public Key Encryption (HPKE) with JSON Web Encryption (JWE)) to Proposed Standard

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 <iesg-secretary at ietf.org<mailto:iesg-secretary at ietf.org>> 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
last-call at ietf.org<mailto:last-call at ietf.org> mailing lists by 2026-05-27. Exceptionally, comments may
be sent to iesg at ietf.org<mailto:iesg at ietf.org> 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 -- jose at ietf.org<mailto:jose at ietf.org>
To unsubscribe send an email to jose-leave at ietf.org<mailto:jose-leave at ietf.org>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20260520/298beed6/attachment-0001.htm>