- From: Trevor Perrin <trevp@trevp.net>
- Date: Fri, 17 Oct 2014 15:18:18 -0700
- To: Brian LaMacchia <bal@microsoft.com>
- Cc: Mark Watson <watsonm@netflix.com>, Richard Barnes <rlb@ipv.sx>, Harry Halpin <hhalpin@w3.org>, "public-webcrypto@w3.org Working Group" <public-webcrypto@w3.org>
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
Received on Friday, 17 October 2014 22:18:45 UTC