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

I tried to capture some of the comments from Ilari on KEMs here:
https://github.com/selfissued/draft-ietf-jose-fully-specified-algorithms/pull/4

Before the registry experts get flooded with Kems, Hybrid Kems, and Hybrid
Composites, we should at least get some guidance in place on what makes a
KEM "fully specified".

I think the KDF part is the main piece, in other words a KEM algorithm is
fully specified, if it implies the use of a single KDF.

But we have a similar situation with ECDH-ES, and it seems the convention
at least from HPKE is to name the KEM after the curve and KDF, for example
"DHKEM(P-384, HKDF-SHA384)"...
https://www.iana.org/assignments/hpke/hpke.xhtml#hpke-kem-ids

I assume RSA Kem would look sorta similar if it were added to the HPKE
registry... It is surprising we don't see RSA KEM including some indication
of strength in the algorithm identifier, in the examples we see "RSA-KEM
with a 3072-bit key and KDF3 with SHA-256;" ... and I see ASN.1 with
"CMS-RSA-KEM-2023".

What would a "fully specified RSA Kem algorithm ID" look like?

I'd imagine something like "RSA-KEM-3072-KDF3-SHA-256" ?

OS

On Mon, Feb 12, 2024 at 4:55 PM Orie Steele <orie@transmute.industries>
wrote:

> Inline:
>
> On Mon, Feb 12, 2024 at 3:09 PM Ilari Liusvaara <ilariliusvaara@welho.com>
> 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
>> COSE@ietf.org
>> https://www.ietf.org/mailman/listinfo/cose
>>
>
>
> --
>
>
> ORIE STEELE
> Chief Technology Officer
> www.transmute.industries
>
> <https://transmute.industries>
>

-- 

ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>