On Wed, Aug 13, 2014 at 9:39 PM, Mike Jones <[email protected]> wrote:
> 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.
I didn't find the existing spec a burden. My JWK-derived system uses {
"kty" : "Ed25519", vk : "the base64url-encoded verifying key" } and
uses "Ed25519" as alg as well. (In the less necessary JWK private key
representation "sk" : "..." is used for the secret part).
Is there some economy that makes it desirable to have a Ed25519 JWK
look similar to any other elliptic curve key that only uses one
(opaque?) parameter? The constant-time implementation (no secret
branching) is monolithic, specialized to that curve and is not built
out of reconfigurable pieces.
Curve1174 "Elligator" is another elliptic curve system by DJB etc.
that looks like it shares some of the attributes of Ed25519.
Daniel Holth
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
