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 <[email protected]> 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 _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
