On Tue, 18 Jun 2024 at 17:32, Ilari Liusvaara <[email protected]>
wrote:
> On Mon, Jun 17, 2024 at 07:44:04PM +0000, Mike Ounsworth wrote:
> >
> >
> > 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.
>
> And JOSE does exactly that, and as result, integrating (direct) HPKE
> is quite thorny. The indirect case (act as PKE to encrypt CEK) is
> much easier.
>
> Whereas COSE has very different kind of design, which makes integrating
> HPKE very easy. It even gives multi-recipient for free!
>
>
> > 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.
>
> Due to technical limiations in JOSE and COSE, KEMs must be Direct
> Key Agreement algorithms.
>
> Fortunately, the main Direct Key Agreement algorithm in JOSE and COSE
> is ECDH-ES, which is extremely similar to KEMs. Where "extremely
> similar" means operations map one-to-one.
>
> I estimate that defining the needed algorithms for native KEM support
> to both JOSE and COSE would take about a page of spec text (not
> counting IANA considerations).
>
Integrating the PQ/T hybrid scheme (ECDH-ES+ML-KEM) into JWE introduces the
same complexities as HPKE that require modifications to the existing JOSE
framework. In both cases, a new parameter would have to be defined to carry
the KEM ciphertext. As discussed previously, it is not essential to use the
one-shot API in HPKE. It is easy
to split the HPKE suite information differently for key encryption and
direct algorithm to align with JWE. For example:
1. Direct: {alg: HPKE-Base-P256-SHA256, enc: A128GCM} (this could lead to
mismatches in strength, and hash function, and poor interop)
2. Indirect: { alg: HPKE-Base-P256-SHA256-A128KW, enc: A128GCM }
-Tiru
>
>
> > 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.
>
> This is the case in JOSE, but not in COSE. Bulk encryption in COSE is
> not required to be symmetric.
>
>
> > I would cherry-pick the useful ideas out of 9180 and add the minimum
> > amount of new message types to support KEMs.
>
> In JOSE and COSE, it is not about new message types, but new algorithms
> of already existing type.
>
> At minimum:
>
> - KEM (Direct Key Agreement)
> - KEM+A256KW (Key Agreement with Key Wrap/Wrappping).
>
>
>
>
> -Ilari
>
> _______________________________________________
> jose mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
_______________________________________________
jose mailing list -- [email protected]
To unsubscribe send an email to [email protected]
