Thanks for both of your detailed analysis of the encryption situation, Brian
and Ilari. I'll endeavor to capture this information in my presentation for
our discussions in Brisbane.
Thanks,
-- Mike
-----Original Message-----
From: jose <[email protected]> On Behalf Of Ilari Liusvaara
Sent: Saturday, March 2, 2024 2:17 AM
To: [email protected]
Subject: Re: [jose] I-D Action:
draft-ietf-jose-fully-specified-algorithms-01.txt
On Fri, Mar 01, 2024 at 02:41:20PM -0700, Brian Campbell wrote:
> For JOSE encryption, I think the 4 deprecated algorithms would be
> ECDH-ES,
> ECDH-ES+A128KW, ECDH-ES+A192K, and ECDH-ES+A256KW.
And for COSE, there is additionally SHA512 variant of ECDH-ES, plus SS versions
of all those, making 10 total.
> But it seems like there could be as many as 20 new algorithms - one of
> each of the above combined with each of EC/P-256, EC/P-384, EC/P-521,
> OKP/X25519, and OKP/X448. Although that list could probably be
> trimmed down to only include combinations that "make sense" together
> based on bit strength. Maybe that's where Ilari's 12 comes from?
> Though I get 10 when I try to make such a list:
>
> ECDH-ES w/ EC/P-256, EC/P-384, EC/P-521, OKP/X25519, and OKP/X448 (5)
> ECDH-ES+A128KW w/ EC/P-256 and OKP/X25519 (2) A192KW w/ EC/P-384 (1)
> ECDH-ES+A256KW w/ EC/P-521 and OKP/X448 (2)
>
> (5+2+1+2 = 10)
There is the 6th curve (secp256k1, a.k.a. the Bitcoin curve), but it is in a
bit of limbo if it is allowed in ECDH or not.
But if that is left out, the list is as above.
And might make sense to use matching hash function. So SHA-384 for
P-384 and SHA-512 for P-521 and X448.
For COSE, the number is doubled because of the SS variants.
Oh and for extra fun, there is the question if one should use AES-192 or
AES-256 with P-384. The support for AES-192 is much poorer than support for
AES-256. Previously this did not matter because one could use either with
P-384, but now one has to use the chosen one in JOSE (in COSE, the Key
Agreement with Key Wrap algorithms are just shortcuts, as it is possible to
compose those from primitive component algorithms).
> Regardless, I'm not sure how I feel about the combinatorial expansion
> there. Especially in the context of adding and deprecating algs into
> specs and code with existing widespread usage.
There's also the issue what if some algorithms do something subtly different.
Very mild example is someone adding curves with h != 1, which then use cofactor
ECDH instead of normal ECDH. But the new algorithms could also have other
differences which turn out to be a major PITA to support in implementations.
Which is also something to consider in context of COSE-HPKE/JOSE-HPKE.
There already have been proposals there to do things that are not even possible
to support without breaking changes in some libraries.
-Ilari
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
