Re: [jose] JWK Elliptic Curve key representations and new curves

[Richard Barnes <[e-mail]>]

I think it has to be a new "kty" value, unless the Curve25519 crowd are
willing to do conversion from little-endian to big.  If that's the case, we
could update the "EC" spec to say that "y" is optional in cases where there
is no ambiguity.

It would be very much preferable, however, to keep this on ice until the
CFRG debate settles.  There appear to be all sorts of slight variations in
how these new curves like to represent points, so it will be helpful to
have a more consolidated set of targets, so that we don't have to come up
with N point formats.  It would also be helpful if the proponents of the
various curves could lay down their weapons for a second and agree on a
format that works for all of them.

--Richard


On Thu, Aug 14, 2014 at 4:22 AM, Mike Scott <[e-mail]> wrote:

> Be careful not to confuse Ed25519 with Curve25519. The former uses Edwards
> coordinates in which case (x,y) coordinates are appropriate. The latter
> uses Montgomery coordinates, which only require an x coordinate for the
> special case of an implementation of the Diffie-Hellman key exchange.
>
> In fact all coordinate systems can use a "compressed" form of just x and
> at most 1 bit to indicate the sign of y (recall that x and y are related
> via the curve equation). However compression (or some forms of it) was
> patented, and hence avoided. However I believe that patent has now lapsed
> (?) As I recall IEEE1363 supports a compressed representation of points.
>
> Also "decompression" has a cost associated with it, although this doesn't
> arise for Curve25519 where it is never required to recover the y coordinate
>
>
> Mike Scott
>
> ________________________________________
> From: jose <[e-mail]> on behalf of Daniel Holth <
> [e-mail]>
> Sent: 14 August 2014 03:20
> To: Mike Jones
> Cc: Trevor Perrin; [e-mail]
> Subject: Re: [jose] JWK Elliptic Curve key representations and new curves
>
> On Wed, Aug 13, 2014 at 9:39 PM, Mike Jones <[e-mail]>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose
>
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose
>