On Sat, Jun 15, 2024 at 8:02 AM Orie Steele <[email protected]> wrote:
> Brian wrote: > > > Perhaps it'd be less awkward to do something like JWHPKE that defines > independent JOSE style JSON and compact serializations specifically for > HPKE and is unencumbered by constructs and constraints of RFC7516? > > This is an interesting idea. > Even the sun shines on a dog's... > I assumed we had already moved beyond "normal JWE" some time ago, > Perhaps but while still trying to do unnatural things to/with JWE to make it fit. Things that would be very clumsy and problematic to jam into real world implementations of JWE. > given the structure of a compact HPKE JWT (from the unadopted draft) looks > like this: > > > eyJhbGciOiJIUEtFLUJhc2UtUDI1Ni1TSEEyNTYtQUVTMTI4R0NNIiwiZXBrIjp7Imt0eSI6IkVLIiwiZWsiOiJCTFE0cHBMMFdlendzWjAyYTRtTFlkLVY1NUh2a0trT1hZVFN6NXJ3aWh6Z1BKbFY5M2Z3c2NfRzhLdTNfeHJKdUtST1FaT05HMzUxcmtKNnZ5Z0xDVk0ifX0...cwLUcH4GFHBZqq0Q-u3yHl-3Nb6eUpLg2w-WZyv1PfYi4pdgLyp_Mmw9atlp7NqujqIFgRhZpAvIRgOBlWPSfjGgi5qsUyU0lcY0DdICCPRMdPnA0JGtFI9iP11JbQLldSg-1Fo. > > ( notice the gaps for things we don't need from > https://datatracker.ietf.org/doc/html/rfc7516#section-3.1 ) > > Decoded protected header (after updates to align with COSE): > > { > "alg": "HPKE-Base-P256-SHA256-A128GCM", > "ek": > "BLQ4ppL0WezwsZ02a4mLYd-V55HvkKkOXYTSz5rwihzgPJlV93fwsc_G8Ku3_xrJuKROQZONG351rkJ6vygLCVM" > } > Notice that that doesn't contain the RFC7516 mandated <https://datatracker.ietf.org/doc/html/rfc7516#section-4.1.2> "enc" header parameter. Which IMHO just further confirms an impedance mismatch between JWE and HPKE. > > As Tiru points out, the purpose of the draft is to enable protocols (that > rely on JWT or JSON serialization) to upgrade to PQ or hybrid encryption. > Folks much more versed in these things than I have suggested that that's not necessarily the only or best way to facilitate that. But I'll set that aside for the purposes of this here discussion. > > A JWT is a JWS or a *compact* JWE today, so we have focused on making > "HPKE JWEs". > Oh right, of course. I'd sort of willfully forgotten about that aspect of JWT and its implications here. But I think it'd be much more straightforward to say (and implement) "JWTs can also be represented using the JWHPKEH™ Compact Serialization" than to cram HPKE into "traditional" JWE. Or name it JWE2 as you've called it below or HPKJWE™ or JWE2024 or JWEplus (some of which I hate but just tossing them out). > The fact that an "HPKE JWE" looks similar to a compact JWE using > alg:ECDH-ES, enc: A128GCM, but is different, seems to be causing a lot of > confusion. > I dare say there are quite a few sources of a lot of confusion in all this. > > I had similar confusion with SD-JWT, until I did an implementation, and > then I realized that SD-JWT is like a JWT, but with a ~ on the end, and > some new rules for processing parameters in the payload. > > HPKE JWTs are like normal JWEs, but with some missing parameters (because > HPKE internalizes them) and with some rules for processing new parameters > (ek will be the only new parameter, assuming we can use alg and enc). > > I think this makes HPKE JWTs easier to understand than many other formats > I have reviewed. > > Consider the compact example above, we could make a new kind of compact > JWE, like compact JWE2. > > That allows for this: > > <encoded protected header>.<cipher text> > > Or we could add support for unprotected headers in compact JWE2s: > > <encoded protected header>.<encoded unprotected header>.<cipher text> > I'd suggest that the encapsulated key be pulled out into a top level encoded part. I think this has been kinda discussed in later posts to this thread but something like this (gracious inclusion of unprotected parameters) might work and also be differentiable from compact JWS and JWE: <encoded protected header>.<encoded encapsulated key>.<encoded cipher text>.<encoded unprotected trailer> > > Then we could define a JWT as being a JWS, compact JWE, (compact SD-JWT?) > or a compact JWE2. > > AFAIK, a JWT can never be JSON serialized, which is why SD-JWT has > sections like this that clarify how to verify a JSON serialized SD-JWT: > > > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-09#name-verification-of-the-jws-jso > That whole section is, in my personal opinion, an unfortunate result of the confluence of a number of unfortunate circumstances. I would not consider it as a pattern of anything that should be emulated. > > I bring up SD-JWT, because that draft seems to have taken the approach > Brian has suggested. > Due to the limitations of compact JWTs, there was no place to add "mutable > disclosures", so a new media type and a new reserved character "~" were > needed. > SD-JWT could have overloaded JWE fields, creating JWTs that look like JWEs > but contain disclosures and integrity protected salted hashes... that could > have caused similar confusions. > SD-JWT became distinguishable from JWS and JWE by becoming a distinct > media type application/sd-jwt (which is used to convey a JWS with a ~ and > encoded disclosures) instead of application/jwt (which can be used to > convey a JWE or a JWS) > > If the working group thinks: *<encoded compact jwe2 protected > header>.<cipher text>* is better than <encoded compact jwe protected > header>*.<missing encrypted key>.<missing jwe iv>.*<cipher text> > *.<missing auth tag>* > That seems easy enough to fix. > > Brian what do you think about this? > I would (and have) quibbled with some of the details but much prefer the general approach. And probably not just for the compact serialization. > Ilari wrote: > > > It is impossible to map direct HPKE into what RFC7516 specifies, so what > direct HPKE is essentially doing is using JWE compact and JSON > serializations for something that is not JWE. > > I agree with this. > > Hopefully the example above makes this clear as well. > > > And then indirect HPKE must actually be JWE due to interoperability > reasons. > > I agree with this. > > If we are successful and produce an HPKE alg that can be used in JSON > Serialized JWE Encryptions, we can start adding a recipient that supports > ML-KEM, next to other recipients that support RSA or ECDH. > > If COSE WG is also successful, keys restricted for > HPKE-Base-P256-SHA256-A128GCM in JOSE will also be useful in COSE. > > Of course it will take rough consensus in both groups to ensure we don't > end up with confusing algorithms that are partially specified in different > ways. > Luckily we appear to have a good amount of overlap, and both groups have > now discussed the essentials for adding HPKE to JOSE and COSE. > > I will summarize those essentials here once more, with the hope that > providing clarity addresses the topic of "diminishing returns": > > KEM Info - > https://datatracker.ietf.org/doc/html/rfc9180#name-auxiliary-authenticated-app > Additional Authenticated Data - > https://datatracker.ietf.org/doc/html/rfc9180#section-9.4 > Protected Headers - alg, enc, ek, psk_id > > 2 Layer (Indirect / JSON Serialization, etc...) > HPKE-Base-P256-SHA256-A128GCM upgrades { alg: ECDH-ES+A128KW } ... { enc: > A128GCM } > 1 Layer (A new kind of "direct encryption"... "does not exist in JWE") > HPKE-Base-P256-SHA256-A128GCM upgrades { alg: ECDH-ES, enc: A128GCM } > > Hopefully this email is helpful for the folks who are new to the > discussion of HPKE in the context of JOSE and COSE. > > Regards, > > OS > > > On Sat, Jun 15, 2024 at 7:48 AM Ilari Liusvaara <[email protected]> > wrote: > >> On Fri, Jun 14, 2024 at 04:39:03PM -0600, Brian Campbell wrote: >> > >> > >> > At best an awkward fit seems to be putting it mildly. But I might >> suggest >> > that the awkwardness comes from trying to fit HPKE into JWE itself. >> > >> > Perhaps it'd be less awkward to do something like JWHPKE that defines >> > independent JOSE style JSON and compact serializations specifically for >> > HPKE and is unencumbered by constructs and constraints of RFC7516? >> >> It is impossible to map direct HPKE into what RFC7516 specifies, so what >> direct HPKE is essentially doing is using JWE compact and JSON >> serializations for something that is not JWE. And then indirect HPKE >> must actually be JWE due to interoperability reasons. >> >> >> Things are very different in COSE: It is trivial to map direct HPKE into >> what RFC9052 specifies, and such mapping gives indirect HPKE for free. >> >> >> >> >> -Ilari >> >> _______________________________________________ >> jose mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> > > > -- > > > ORIE STEELE > Chief Technology Officer > www.transmute.industries > > <https://transmute.industries> > _______________________________________________ > jose mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- _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]
