Re: [jose] [COSE] COSE/JOSE elliptic curves and their relationship with key types

[Ilari Liusvaara <[e-mail]>]

On Mon, Jul 12, 2021 at 08:46:00PM -0700, Benjamin Kaduk wrote:
> Hi Michael,
> 
> Thanks for sharing your thoughts.
> 
> On Wed, Jul 07, 2021 at 06:42:35PM -0400, Michael Richardson wrote:
> > 
> > Benjamin Kaduk <[e-mail]> wrote:
> >     > As written, that seems to allow a notion of "consistent" that is not
> >     > strictly 1:1, but all of the curves defined so far only have that 1:1
> >     > mapping, and trying to use any other "kty" for an existing curve would run
> >     > into interop problems with existing implementations that reject other "kty"
> >     > values for that curve.
> > 
> > It seems to me that we think it's always gonna be 1:1, but that we admit that
> > we can't predict the future, and so we are providing some extra rope.
> 
> There is of course a reason that I am asking the question.  I had hoped
> to separate the initial batch of responses to the general question from the
> specific case, so I didn't mention it in the initial note, but
> draft-ietf-lwig-curve-representations registers the Wei25519 and Wei448
> elliptic curves (the short-Weierstrass analogues of Curve25519 and
> Curve448), and currently lists the key type for both as "EC2 or OKP".

To my knowledge, the goals of those curves are:

- Be compatible with devices with arbitrary-curve short-Weierstrass
  acceleration.
- Be compatible with legacy EC algorithms (e.g., ECDH, ECDSA). However,
  there are some nasty edge cases here.
- Use more efficient base fields and ladders where acceleration is not
  available.

> To my knowledge, these curve (representation)s are not in wide use and
> there is thus not a well-established single point representation to use
> with them.  However, since the intent of the work is to expose the CFRG
> curves' benefits to implementations tailored to short-Weierstrass curves,
> which in turn would be likely to use the "EC2" representation in its
> interfaces, it seems like if we were to pick a preferred representation it
> would be "EC2".

There is well-established encoding for short-Weierstrass curves to bytes:
the secg encoding (there are both compressed and uncompressed variants).
However, These curves are intended to be worked with general-purpose
short-Weierstras implemenations, and COSE EC2 (and JOSE EC) are intended
for the same class, so EC2 is the correct choice, and allowing both
would just add more code.


-Ilari