- From: Trevor Perrin <trevp@trevp.net>
- Date: Fri, 17 Oct 2014 16:56:32 -0700
- To: Mark Watson <watsonm@netflix.com>
- Cc: Brian LaMacchia <bal@microsoft.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 4:39 PM, Mrk Watson <watsonm@netflix.com> wrote: > > > On Fri, Oct 17, 2014 at 4:16 PM, Trevor Perrin <trevp@trevp.net> wrote: >> >> You're also assuming the JWK "EC" type, which requires full x and y >> coordinates, so disallows single-coordinate or compressed public keys. > > > Do you think they would use a different "kty" value if JWK was extended for > single-coordinate or compressed public keys ? I joined one call about 25519, and I think Mike Jones suggested defining a different "kty" for 25519, instead of trying to change the "EC" type. So I don't know what the best representation of compressed Edwards or single-coordinate Montgomery points in JWK is. I guess I'd leave that decision to a new algorithm. >> Those could be fixed - whether all this is saving any effort or >> cleaner than just defining new algorithms, I don't have strong >> opinions on. > > > I don't much care either, myself, but others have expressed strong opinions > in the past that adding to the NamedCurve list is superior to defining new > algorithms and noone has expressed the converse opinion. I weakly prefer just defining new algorithms, I think these extension points messy-up the text; they replace almost all the substance of the existing algorithms; and if they're not exactly right we'll need new algorithms anyways. Trevor
Received on Friday, 17 October 2014 23:57:00 UTC