Re: [jose] [COSE] JOSE/COSE RSA Kem without HPKE?

[Orie Steele <[e-mail]>]

Inline:

On Mon, Feb 12, 2024 at 3:09 PM Ilari Liusvaara <[e-mail]>
wrote:

> On Mon, Feb 12, 2024 at 12:41:52PM -0600, Orie Steele wrote:
> > See https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5990bis/
> >
> > Do we expect to see RSA Kem support in JOSE and COSE without the use of
> > HPKE?
> >
> > If so, how do we identify RSA keys for use with KEMS? How do we transport
> > KEM CT ?
>
> I would imagine keys specify which KEM those keys use.
>
> And then there would be KEM algorithms analogous to ECDH-ES ones (there
> are a few details about ECDH-ES algorithms that need tweaking for
> things to work with KEMs).
>
> IIRC, only three differences are needed:
>
> - KEM shared secret goes where ECDH result used to go.
> - Where one sticks the KEM ciphertext.
> - Some trivial encaps/decaps process stuff.
>
> Things like KDFs can just be reused as-is.
>
>
> > One option would be to reuse what we have in the JOSE HPKE draft, to
> > transport the KEM CT as an ephemeral encapsulated key:
>
> If HPKE uses a header, I would imagine it uses the same one. KEM CT
> can be assumed to be a byte string.
>
>
> > Similar to the discussions we have had for ECDH-ES+A128KW vs HPKE, let us
> > start a discussion for
> >
> > RSAES-OAEP w/ SHA-256 vs HPKE or Plain RSA Kem (TBD)
> >
> > - https://www.rfc-editor.org/rfc/rfc7518.html#section-4.3
> > - https://www.rfc-editor.org/rfc/rfc8230.html#section-3
>
> Well, there is already RSA support.
>
> However, stuff like this might be more interesting:
>
> https://github.com/lamps-wg/draft-composite-kem/pull/11
>
>
Yes, this is another reason to ask... will we see composite kems as
standalone building blocks (like RSA Kem)
Or will we see HPKE Suites that pair those building blocks with specific
choices of KDF and AEAD.



>
> > The reason I raise this, is that Ilari mentioned wanting to use JOSE
> HPKE's
> > Integrated Encryption and Key Encryption modes, without HPKE but with
> other
> > KEMs, so considering how RSA Kem might be supported in JOSE and COSE
> seems
> > worth discussing.
>
> Integrated Encryption can not work with KEMs.
>

Of course, you are correct.


>
> In JWE and COSE, KEMs act similarly to ECDH-ES and have the same types
> (Direct Key Agreement, Key Agreement with Key Wrap(ping)).
>
> Anything one can use ECDH-ES for, one should be able to use KEM for.
>

epk is already used for this case, the ES part, is what pairs with the
"epk" part.


>
> > Is it ok if JOSE uses "epk" and JWK, COSE uses a new header
> > parameter instead of using "epk" and COSE Key?
>
> Well, I think using new header parameter is easier for implementations
> than using a JWK (or COSE_Key). The JWK seems just pointless wrapping
> of a byte string.
>

It's not pointless.
It uses the existing code points for headers, which reduces the burden on
applications that will have to keep processing those headers.
The applications only need to switch on "alg", and then process the
associated epk.... which is what they are already doing for
"ECDH-ES" and "epk" today.

If we didn't have these existing application processing considerations, it
would be easier to say adding a new header param is the correct solution in
my opinion, but we are probably headed for testing RSAES-OAEP, ECDH-ES, and
HPKE recipients for the same encrypted messages.... if we add
RSA-KEM+A128KW to that mix, it's better to consider the design cost of that
now... before the drafts become standards... I think either path will work,
but we should force the API design to align, for the sake of developers...
I would call it a win if JOSE and COSE handle this in a similar way, and a
loss if they decide to handle it differently... I am not attached to the
design using epk, but I do think it is easier for implementations that have
to keep supporting ECDH-ES alongside HPKE and RSA Kem.



>
>
>
>
> -Ilari
>
> _______________________________________________
> COSE mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cose
>


-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>