I mentioned in my earlier email that I only implemented "Key Encryption", as it was fairly straight-forward and fitting existing JWE structures. I didn’t implement "Integrated Encryption" as it looked rather challenging to retrofit the ability to encrypt payload instead of CEK with an "alg".
After reading Brian Campbell’s analysis, I feel confirmed in my gut feeling that supporting Integrated Encryption would result in a rather distorted spaghetti code that is hard to maintain and hard to audit. I would therefore propose to postpone "Integrated Encryption“. If there is actual need for it (not just „because HPKE can“), it might be better to define this in a separate standard, so we can move forward with HPKE Key Encryption for now? > On 19. Jun 2025, at 04:15, Aaron Parecki <aaron=40parecki....@dmarc.ietf.org> > wrote: > > After reflecting on some of the additional responses on the list yesterday > and reviewing the doc further, I have to say I agree with many of the > concerns expressed, and withdraw my support for publishing at this time. > > > On Thu, Jun 12, 2025 at 6:12 PM Aaron Parecki <aa...@parecki.com > <mailto:aa...@parecki.com>> wrote: >> I support publication. >> >> --- >> Aaron Parecki >> > _______________________________________________ > jose mailing list -- jose@ietf.org > To unsubscribe send an email to jose-le...@ietf.org
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list -- jose@ietf.org To unsubscribe send an email to jose-le...@ietf.org
