My understanding is that single-coordinate representations (OKP) are safer because they reduce the scope for invalid curve attacks, but that they were patent-encumbered for many years. With a double-coordinate representation you have to carefully check that (x,y) satisfies the curve equation. With a single coordinate you instead calculate y from x using the curve equation (if you need it), so it can’t fail to satisfy it. IMO, that should be the preferred representation for any new curves.
Note that if you want to be completely unambiguous then you typically want a single coordinate (x) plus a bit to say which of the two roots to use for the y-coordinate. RFC 8037 allows this by not committing to what “x” represents, but RFC 8152 for COSE says that the “x” field is the little-endian encoding of the x-coordinate specifically, so you might need a different type. (In fact, EdDSA public keys are the *y* coordinate plus a single bit to say which x-coordinate to use, so I think COSE is already breaking its own contract). — Neil > On 13 Jul 2021, at 04:46, Benjamin Kaduk <[email protected]> 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, 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". > >> It also seems that we might also be thinking that there might be other ways >> to encode the keys (into bytes), but that mostly it is the case that we have >> a single encoding that we stick to. > > But for a protocol don't we kind of only want a single encoding anyway? > >> (Why did we call it "EC2". Huh) > > I feel like I used to know this, but am drawing a blank. Maybe that there > are two coordinates included? > > Thanks again, > > Ben > >>> Do we expect a strict relationship where each curve has exactly one "kty" >>> that it's used with? If not, in what scenario(s) would there be multiple >>> "kty" values to use with a single curve? >> >> >> -- >> Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) >> Sandelman Software Works Inc, Ottawa and Worldwide >> >> >> >> > > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose -- ForgeRock values your Privacy <https://www.forgerock.com/your-privacy> _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
