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