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

Trevor,

Look again - I just updated it.

...Mark

On Fri, Oct 17, 2014 at 3:18 PM, Trevor Perrin <trevp@trevp.net> wrote:

> On Fri, Oct 17, 2014 at 11:16 AM, Brian LaMacchia <bal@microsoft.com>
> wrote:
> > 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.
>
>
> If I'm looking in the right place, it's not clear the current text
> supports compressed public keys or non-Weierstrass public keys.
>
> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html
>
> If people want new curves to use compressed points, and Edwards
> coordinates (Ed25519, some of the NUMS) - then I think the text will
> need changes / extensions.
>
> Looking over the "ECDH" algorithm:
>
> Import spki - RFC 5480 2.2 doesn't mandate support for compression:
> "MUST support the uncompressed form and MAY support the compressed
> form".  It specifies compression via SEC1 which uses Weierstrass (not
> Edwards).
>
> Import pkcs8 - refers to RFC 5480 2.2, see above.
>
> Import jwk - JWA 6.2.1: "SEC1 [SEC1] point compression is not
> supported for any values."
>
> Import raw - X9.62 Annex A specifies compression using Weierstrass
> (not Edwards).
>
> Export spki - "Set the subjectPublicKey field to the octet string that
> represents the Elliptic Curve public key [...] using the uncompressed
> form."
>
> Export jwk - "Set the x attribute [...] Set the y attribute"
>
> Export raw - Refers to X9.62 Annex A, which uses Weierstrass.
>
>
> Trevor
>