On Mon, Jun 16, 2025 at 7:30 PM Michael Jones <[email protected]> wrote:
> > *From:* Neil Madden <[email protected]> > *Sent:* Friday, June 13, 2025 3:42 AM > > > > I’m more and more convinced that Brian’s suggestion to define a new JWHPKE > would be a better solution than trying to crowbar this into JWE. ( > https://mailarchive.ietf.org/arch/msg/jose/ssmlqF2lUGXwqnhD8SU7l2E1Aqg/) > > > > That would defeat the entire purpose of the work. The purpose is to be > able to use JWE encryption with HPKE algorithms. The IETF is going all-in > on HPKE as the new way of expressing encryption, including PQ encryption. > This spec lets JWE and JWTs ride that wave. > > > > This is particularly important for JWTs, which are now widely used in ways > that the authors never imagined. Doing something that’s not a JWE wouldn’t > help JWTs. > I've seen this assertion or variations thereof made a few times but it strikes me as a rather limiting perspective. It would seem to me that a soundly defined JOSE-style compact serialization container for HPKE that can wrap JWTs in basically the same way that JWE does (even calling it a new kind of JWE, if that helps) would similarly help JWTs while better positioning for the future too. However, if the perception/consensus is that it really has to be a JWE to garner these benefits, then an actual update[*] to RFC 7516 would be more appropriate. That would entail literally updating RFC 7516 to describe the new behavior for the direct/integrated HPKE "alg"s from the existing JWE alg normative definition of identifying "the cryptographic algorithm used to encrypt or determine the value of the CEK" to something that defines the HPKE alg behavior and where the output artifacts go. it would also update the "enc" definition to relax the requirement that the header "MUST be present" and say that "enc" isn't used with this new class of HPKE algs. Presuming they are needed (I'm not convinced of the utility but don't care to object) the HPKE key encryption algorithms fit within the existing JWE constructs so don't depend on updating the underlying RFC. But they would have their own distinct alg values to distinguish from the direct/integrated HPKE behavior. * I am aware that the sentence, 'This specification updates the "enc" definition in Section 4.1.2 of [RFC7516] by allowing the "enc" value "int" when the "alg" value is a JOSE-HPKE algorithm.' was added to the Overview section in draft -10 but I mean a legitimate procedural RFC update with commensurate document content. -- _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]
