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. MIMI also seems to be considering something like this, where MLS (see https://www.iana.org/assignments/mls/mls.xhtml#mls-ciphersuites ) and CBOR are used together, instead of COSE or mixed in with COSE algorithms, here is the draft: https://datatracker.ietf.org/doc/html/draft-ietf-mimi-content-04#section-4.4 I assumed we had already moved beyond "normal JWE" some time ago, 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" } 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. A JWT is a JWS or a *compact* JWE today, so we have focused on making "HPKE JWEs". 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 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> 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 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? 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]
