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] <mailto:[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] <mailto:[email protected]> To unsubscribe send an email to [email protected] <mailto:[email protected]> -- ORIE STEELE Chief Technology Officer <https://urldefense.com/v3/__http:/www.transmute.industries__;!!FJ-Y8qCqXTj2!cAitRU1KImT-cH9eT4MTBsOQngCZdphO4L65tRCW7zsZnN-ltdoHX8D1VsOSOP4uCLa8r8QnMDe_QRShi9F2Mm1MjttGvdic7mS9$> www.transmute.industries <https://urldefense.com/v3/__https:/transmute.industries__;!!FJ-Y8qCqXTj2!cAitRU1KImT-cH9eT4MTBsOQngCZdphO4L65tRCW7zsZnN-ltdoHX8D1VsOSOP4uCLa8r8QnMDe_QRShi9F2Mm1MjttGvVMlGhMy$> _______________________________________________ jose mailing list -- [email protected] <mailto:[email protected]> To unsubscribe send an email to [email protected] <mailto:[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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
