[jose] JWK Elliptic Curve key representations and new curves

[Mike Jones <[e-mail]>]

It has come up in recent discussions in the CRFG, the W3C WebCrypto working group, and the TLS working group that not all elliptic curves or curve protocols use two coordinates (x and y) in their public key representations.  For instance, a Curve25519 public key is a single 32-byte value.  Especially in light of the request by TLS to the CRFG to recommend new curves, and that some of the curves in consideration use only a single value in their public key representation, I believe that JOSE should consider how to represent such keys as JWKs.

I see there being two logical ways to address this:

CHOICE 1 - MAKE THE "EC" KEY TYPE MORE FLEXIBLE:  One obvious possibility is to make it a property of the "crv" parameter for JWKs with "kty": "EC" what fields are required.  So for instance, when "crv" is "P-256", "P-384", or "P-521", both "x" and "y" members would be used, but other curves might use a different set of members, such as just "x" for public keys.

CHOICE 2 - USE A DIFFERENT KEY TYPE:  Another possibility is to leave the "kty": "EC" definition as it is but to define a related "kty": "EC1" value to be used by elliptic curves for which only one value "x" is used in the public key representation and an additional value "d" is used in the private key representation.

Within choice 2, there are actually two sub-choices available to us:

CHOICE 2A - DEFINE A NEW KEY TYPE VALUE IN JWA NOW:  If we think that there are only two kinds of elliptic curve key representations that we will ever care about, we could define the second one in JWA now.  However, this would almost certainly start a debate within JOSE about whether we should add any additional curve definitions using this new key type.  If we do, it should almost certainly be because we have followed the CFRG's and TLS's lead in the new curve choices, although doing so would almost certainly further delay our completion.
CHOICE 2B - DEFINE THE NEW KEY TYPE IN A NEW SPEC:   This could be done by writing an individual draft that registers "kty": "EC1" and later possibly adopting it as a working group item.  This would allow our current specs to proceed as-is, while giving us time to sync with CFRG and TLS as their curve choices move forwards.

One additional pesky detail worth noting is that the normal Curve25519 key representation uses little-endian 32-bit numbers whereas SEC1 (which we use for "x", "y", and "d") uses big-endian numbers.  So for any of these choices above, we'd also have to decide whether to allow different curves to specify different endianness, require all to use big-endian representations, or to say that for some curves, the value is an octet array of a given size and be silent on endianness.

While I'm reluctant to even bring this up at this point in the development of our specs, I also don't want those designing potential applications of JWKs to believe that their choices of curves are limited by decisions that JOSE has made.  It's clear that JWK can be extended to accommodate curves using only a single value in their public key representations.

How do you think we should do that?

                                                                -- Mike

P.S.  Thanks to Trevor Perrin for private discussions that informed some of the contents of this note.