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

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 07:20:17 UTC