Likewise - I think Orie's described approach is sane Mike Prorock CTO - mesur.io
On Sat, Feb 10, 2024, 14:47 Michael Jones <[email protected]> wrote: > I support the design philosophy described by Orie below. > > > > -- Mike > > > > *From:* jose <[email protected]> *On Behalf Of *Orie Steele > *Sent:* Saturday, February 10, 2024 1:15 PM > *To:* Ilari Liusvaara <[email protected]> > *Cc:* JOSE WG <[email protected]> > *Subject:* Re: [jose] HPKE Compact JWE Demo > > > > 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 >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
