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> wrote:

> On Thu, Oct 16, 2014 at 6:51 PM, Mark Watson <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
>

Received on Friday, 17 October 2014 14:59:08 UTC