Thank you Mike, It might be some confirmation bias on my side but I found the perspective you shared to be very helpful.
On Mon, Jun 17, 2024 at 1:44 PM Mike Ounsworth <Mike.Ounsworth= [email protected]> wrote: > Hey Brian, Neil, Ilari, > > > > I am, at best, a tourist in JOSE / COSE, but I’ve been heavily involved in > integrating KEMs into LAMPS, so Orie asked me to share experience. > > > > My TL;DR #1: If you already have an encryption framework that separates > out the asymmetric key establishment from the symmetric content encryption, > then integrating HPKE (RFC9180) is … awkward at best; it may be wise to > borrow useful ideas from HPKE (like the domain separation properties that > you get from LabeledExtract), but taking HPKE in its entirety is > problematic. > > > > My TL;DR #2: KEMs are a different interface from either Key Transport (ie > pure PKE), or Key Agreement (DH) and probably should get their own message > types. > > > > > > So, basically, LAMPS is anticipating there being X.509 certificates that > contain ML-KEM public keys, and therefore the need for protocols to be able > to encrypt for them. Within LAMPS we own a couple of encryption protocols, > and we started with CMS which underpins S/MIME email, and CMP which is a > cert enrollment protocol and uses challenge encryption for proving the > client has the private key, and for encrypting the final certificate back > to the client. > > > > In CMS, the asymmetric key establishment and symmetric content encryption > are handled at separate layers. Trying to merge them just so that we could > support HPKE seemed excessive, so instead we added KEM support to CMS > directly via a new message type KEMRecipientInfo (see > draft-ietf-lamps-cms-kemri) and we also recently hit some issues with > insufficient domain separation which we addressed with some > 9180LabeledExpand-like enhancements to the AES key derivation (see > draft-ietf-lamps-cms-cek-hkdf-sha256). > > > > CMP uses encryption algorithms in an entirely different way: they are used > to establish a MAC key between client and server which is then used to > authenticate subsequent messages. Again, HPKE is a bad fit so we added KEM > support directly in a way similar to CMS above (see > draft-ietf-lamps-rfc4210bis section 4.3.4) > > > > > > Again, I’m just a tourist in JOSE / COSE, but this feels like CMS where > you already have the asymmetric “alg” and symmetric “enc” separated out. > Trying to merge these back together so that you can take advantage of the > one-shot HPKE API seems like a whole lot of complex breaking changes in the > name of simplicity. I would cherry-pick the useful ideas out of 9180 and > add the minimum amount of new message types to support KEMs. > > > > I have not been following this thread in detail, so I hope this was > helpful, and sorry if I’m misunderstanding what the debate is about. > > > > --- > > *Mike* Ounsworth > > > > *From:* Brian Campbell <[email protected]> > *Sent:* Monday, June 17, 2024 1:19 PM > *To:* Orie Steele <[email protected]> > *Cc:* JOSE WG <[email protected]> > *Subject:* [EXTERNAL] [jose] Re: HPKE and diminishing returns > > > > On Sat, Jun 15, 2024 at 8: 02 AM Orie Steele <orie@ transmute. industries> > wrote: Brian wrote: > Perhaps it'd be less awkward to do something like > JWHPKE that defines independent JOSE style JSON and compact serializations > specifically > > > > > > 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 > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc7516*section-3.1__;Iw!!FJ-Y8qCqXTj2!cAitRU1KImT-cH9eT4MTBsOQngCZdphO4L65tRCW7zsZnN-ltdoHX8D1VsOSOP4uCLa8r8QnMDe_QRShi9F2Mm1MjttGvY2OYpwy$> > ) > > 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://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc7516*section-4.1.2__;Iw!!FJ-Y8qCqXTj2!cAitRU1KImT-cH9eT4MTBsOQngCZdphO4L65tRCW7zsZnN-ltdoHX8D1VsOSOP4uCLa8r8QnMDe_QRShi9F2Mm1MjttGvXaCQdrc$> > "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 > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-09*name-verification-of-the-jws-jso__;Iw!!FJ-Y8qCqXTj2!cAitRU1KImT-cH9eT4MTBsOQngCZdphO4L65tRCW7zsZnN-ltdoHX8D1VsOSOP4uCLa8r8QnMDe_QRShi9F2Mm1MjttGvTyXYuFh$> > > > > 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 > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc9180*name-auxiliary-authenticated-app__;Iw!!FJ-Y8qCqXTj2!cAitRU1KImT-cH9eT4MTBsOQngCZdphO4L65tRCW7zsZnN-ltdoHX8D1VsOSOP4uCLa8r8QnMDe_QRShi9F2Mm1MjttGvTJ5J7hE$> > Additional Authenticated Data - > https://datatracker.ietf.org/doc/html/rfc9180#section-9.4 > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc9180*section-9.4__;Iw!!FJ-Y8qCqXTj2!cAitRU1KImT-cH9eT4MTBsOQngCZdphO4L65tRCW7zsZnN-ltdoHX8D1VsOSOP4uCLa8r8QnMDe_QRShi9F2Mm1MjttGvepkU7G-$> > 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://urldefense.com/v3/__http:/www.transmute.industries__;!!FJ-Y8qCqXTj2!cAitRU1KImT-cH9eT4MTBsOQngCZdphO4L65tRCW7zsZnN-ltdoHX8D1VsOSOP4uCLa8r8QnMDe_QRShi9F2Mm1MjttGvdic7mS9$> > > [image: Image removed by sender.] > <https://urldefense.com/v3/__https:/transmute.industries__;!!FJ-Y8qCqXTj2!cAitRU1KImT-cH9eT4MTBsOQngCZdphO4L65tRCW7zsZnN-ltdoHX8D1VsOSOP4uCLa8r8QnMDe_QRShi9F2Mm1MjttGvVMlGhMy$> > > _______________________________________________ > 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.* > -- _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]
