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

On Thu, Oct 16, 2014 at 6:01 PM, Richard Barnes <rlb@ipv.sx> wrote:

>
>
> On Thu, Oct 16, 2014 at 5:55 PM, Trevor Perrin <trevp@trevp.net> wrote:
>
>> On Thu, Oct 16, 2014 at 10:25 AM, Harry Halpin <hhalpin@w3.org> wrote:
>> >>
>> >> From: Mark Watson [mailto:watsonm@netflix.com]
>> >>
>> >> (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
>> >>
>> >> If any of these things are not true for some potential future named
>> curve then the curve could only be added to the existing ECDSA and ECDH
>> algorithms if the key format concerned is not supported. Otherwise, the
>> curve would have to be added as a new algorithm instead.
>>
>>
>> Hi everyone,
>>
>> I think new curves may want single-coordinate or compressed public-key
>> formats, and may do other things differently from X9.62/63.  At least,
>> this is true for current uses of 25519.
>>
>> Is there anything here that would make it hard to just add new curves
>> via new algorithms (like my "ECDH-CURVE25519" draft)?
>>
>
> AFAICT, that should still be possible.  That's obviously a more
> heavy-weight option, though.
>

​Only marginally, IMO. That's the decision here: make it possible to
override more of the existing ECDH / ECDSA algorithms or ask new curves
that are "different" to define new algorithms. If the first option means
you end up overriding most or all of the existing algorithms then the work
for a new curve is the same, but then the new algorithm option is cleaner.

So, what I am looking for is a precise description of exactly which items
(1) - (8) would need to be overridden for Curve 25519.

...Mark​



> --Richard
>
>
>>
>> Trevor
>>
>>
>