On Fri, Dec 13, 2024 at 09:22:32PM +0200, Ilari Liusvaara wrote: > On Wed, Dec 11, 2024 at 01:03:11PM -0600, Orie Steele wrote: > > On Wed, Dec 11, 2024 at 12:52 PM Ilari Liusvaara <[email protected]> > > wrote: > > > > > > > > Both draft-ietf-jose-hpke-encrypt and draft-ietf-cose-hpke need to have > > > concept of COSE-HPKE/JOSE-HPKE algorithm disjoint from any concrete > > > algorithm registrations those drafts make. > > > > > > > Please send text, ideally we can cite your text from both specs. > > Opened a PR for COSE-HPKE (still very drafty). Some minor technical > changes (but nothing that would invalidate examples). > > The draft-ietf-jose-hpke-encrypt is more difficult, as it seems to be > nontrivial to specify inputs/outputs without introducing significant > technical changes (especially with Key Encryption, as it has multiple > conflicts with what JWE specifies).
Also posted the JOSE-HPKE PR. It does significant technical changes to Key Encryption. The AAD construction for Key Encryption is modified, the new construction should avoid implementation difficulties[1] and addresses cross-mode and oracle attacks even if JOSE implementation omits mandatory checks. At least the Key Encryption examples need to be redone. [1] Currently, all the recipient processing in JWE works in terms of the JOSE header. Consequently, JWE implementations are unlikely to support using protected header in recpient processing, and adding such support could range from very difficult to outright impossible. The new construction addresses this issue by only using data from (incomplete) JOSE header. -Ilari _______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
