RE: Double-checking with NUMS and Curve 25519 [was Re: Elliptic Curve Extensibility - your view is expected]

See my analysis which I just sent to the list, which I think agrees with Trevor’s on the parts that would have to change for those wishing to use Montgomery x-only coordinates as the wire formats.

I don’t see a problem with those advocating for alternative wire formats having the ability to override in their own extension specs, but for everyone using standard (x,y) (either compressed or uncompressed) what you have is fine and should remain in the main spec.  So I don’t think you need to delegate all the extraction and construction to extension for most curves; I’d keep what you have.

--bal

From: Mark Watson [mailto:watsonm@netflix.com]
Sent: Friday, October 17, 2014 7:59 AM
To: Trevor Perrin
Cc: Richard Barnes; Harry Halpin; public-webcrypto@w3.org Working Group; Brian LaMacchia
Subject: Re: Double-checking with NUMS and Curve 25519 [was Re: Elliptic Curve Extensibility - your view is expected]

Ok, based on the information below, I think it would be relatively easy to expand the extensibility provisions of the existing algorithms to accommodate curve25519:

First, the actual cryptographic operations are already delegated to extension specifications, not restricted to be those defined in X9.62/63.

Given this, it makes sense to delegate the following to the extension specification:
- extraction of the key itself from spki/pkcs8/jwk/raw import
- construction of the subjectPublicKey field of spki export and the privateKey field of pkcs8 export
- construction of the jwk attributes representing the key in jwk export
- construction / interpretation of the data for raw export / import

Just to be clear, this does not mean that WebCrypto is not extensible for other curves that still do not fit with these extensibility provisions. It is always possible to add complete new algorithms.

...Mark


On Fri, Oct 17, 2014 at 12:19 AM, Trevor Perrin <trevp@trevp.net<mailto:trevp@trevp.net>> wrote:
On Thu, Oct 16, 2014 at 6:51 PM, Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote:
>>> >>
>>> >> (1) For SPKI and PKCS8 import / export the curve must be identified
>>> >> entirely and only by the namedCurve choice of the parameters field of the
>>> >> algorithm field of algorithm field of the SPKI
>>> >> (2) for SPKI import, the EC public key can be identified by the
>>> >> "conversion steps defined in Section 2.2 of RFC 5480"
>>> >> (3) for PKCS8 import, the EC private key can be identified by the
>>> >> "conversion steps defined in Section 3 of RFC 5915"
>>> >> (4) for JWK import, the EC public key can be identified by
>>> >> "interpreting jwk according to Section 6.2.2 of JSON Web Algorithms"
>>> >> (5) for JWK import, the EC private key can be identified by
>>> >> "interpreting jwk according to Section 6.2.1 of JSON Web Algorithms"
>>> >> (6) for SPKI export, the EC public key has a defined representation as
>>> >> an octet string
>>> >> (7) for PKCS8 export, the key has a defined representation as "an
>>> >> instance of the ECPrivateKey structure defined in Section 3 of RFC 5915"
>>> >> (8) for JWK export, the EC public key has a representation as "x" and
>>> >> "y" values according to Sections 6.2.1.2 and 6.1.2.3 of JWA, respectively
>>> >> and the EC private key has a representatopm as a "d" value according to
>>> >> 6.2.2.1 of JWA
[...]
>
> So, what I am looking for is a precise description of exactly which items
> (1) - (8) would need to be overridden for Curve 25519.

I don't think there's specs for Curve25519 ECDH (aka "X25519") and
Ed25519 signature keys in SPKI, PKCS8, or JWK.  So my draft just
specified jwk/oct for private keys, and raw for public keys [1].

You could ask the IETF to define those encodings for new curves,
including 25519 if they adopt it.  But even then, I think new curves
should be used with compressed or single-coordinate public keys,
instead of (x,y) coordinates.  So that would still change (I think)
2,4, and 8.

Curve/Ed25519 also doesn't used X9.62/63.  People might want to
consider moving past X9 for other new curves, as well.  It's not free.
It's written for Weierstrass curves (e.g. X9.62 A.4.2).  And there may
be better choices (e.g. Schnorr instead of ECDSA).

Anyways, it seems like a lot of work to anticipate all these
discussions with extension points.  It might be easiest to just let
people copy-and-edit text for new algorithms once we get there.  It
wasn't a big deal when I tried it.

Trevor

[1] http://htmlpreview.github.io/?https://github.com/trevp/curve25519_webcrypto/blob/master/Curve25519_WebCrypto.html