This list feels like mostly complaints about JWE, and not about JOSE HPKE. With compatibility with ECDH-ES JWE shown, I feel pretty confident that the design is on a good track.
If there are problems in the design we have now... those problems are fundamental to JWE. We are adding HPKE support to JWE not making an incompatible alternative to JWE, that only works with HPKE. Adding the ability to upgrade to HPKE without major breaking interface changes is the objective, and greenfielding alternatives to JWE just delays adoption of KEMs and resilience to harvest now decrypt later. The guiding principle is this: Adding HPKE based single recipient and multiple recipient support, with as few changes to JWE as possible. This constraint makes our job simple... What parameters go in headers? How can we accomplish what is needed with as few HPKE specific changes as possible. The current draft does the best at this so far, but it's possible in can be further improved. I don't think your suggestion to concatenate strings values for enc and ct is an improvement. OS On Sat, Feb 10, 2024, 11:46 AM Ilari Liusvaara <[email protected]> wrote: > On Sat, Feb 10, 2024 at 08:39:07AM -0600, Orie Steele wrote: > > Hello Hybrid Public Key Encryption Enthusiasts, > > > > I feel JOSE HPKE is getting very close to stable, we have demonstrated > > compact and json serialization, including key encryption with both HPKE > and > > normal ECDH-ES. > > I feel that JOSE HPKE is far from stable. > > I did start writing review of draft-rha-jose-hpke-encrypt-03, but never > finished that because I hit just too many issues to properly write up. > > > Very abbrevated list (some involve aspects of JWE I only learned about > recently): > > 1) Key Management Modes are defined by JWE, not JWA. > 2) Key Agreement has nothing to do with the way HPKE is used. > 3) The mode descriptions are misleading. > 4) Encapsulated key is neither a structure nor a public key. > 5) Using header parameters for encapsulated key is problematic. > 6) Using JWK for encapsulated key is too complicated. > 7) "enc" existing does not mean it is Key Encryption, just not > Integrated Encryption. > 8) JWE requires serialization invariance, which precludes any > requirement on serialization used. > 9) JWE unions the recipient headers, which precludes requirements on > bucket used for any existing parameter. > 10) JWE allows "enc" to be in recipient header(!) if all recipients have > the same value. *vomit*. This precludes requiring enc to be in any > given bucket. > 11) Using JWE aad for recipients will cause severe implementation > issues. There is clear precedent of not doing that even with > something AEAD-capable. > 12) Mode_auth and mode_auth_psk with Key Encryption are insecure. > > > Deviating from important JWE requirements with single-recipient mode > needs to be done carefully, because doing so can cause nasty issues with > implementations. Doing so in multi-recipient mode is categorically not > acceptable. > > > The simplest way to handle HPKE seal outputs is to just concatenate the > two, no length markers. This would seem to work well for both modes. > > That is: > > JWE_ciphertext = hpke_enc || hpke_ct > JWE_encrypted_key = hpke_enc || hpke_ct > > > > > -Ilari > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
