FWIW, JWA §6.2.1 <http://tools.ietf.org/html/rfc7518#section-6.2.1> defines the "y" parameter as required for "the three curves defined [therein]" which does implies that it may not be required for other curves and the thumbprint rules follow logically.
On Wed, Nov 11, 2015 at 1:37 AM, Ilari Liusvaara <[email protected]> wrote: > On Tue, Nov 10, 2015 at 08:22:53PM -0500, Justin Richer wrote: > > I would lean toward using a new “kty” value for these as the syntax > > is different from existing ones. This will help parsers and existing > > implementations add this in without adding special processing rules: > > code is already set up to branch on “kty” so let’s keep that > > behavior. Note you can still reuse parts of the key definition > > (like “d” is found in both RSA and EC keypairs) without having to > > overload a new syntax since the kty defines a new namespace, > > effectively. I suggest a value of “ED” since they’re all “edwards” > > curves from my quick read. > > 1) Actually, I think "okp" (Octet Key Pair) or something like that > might be more descriptive, since these are keypairs with no structure > outside the box ("oct" or whatever won't do, since that's symmetric, > not asymmetric). This also holds for X25519 and X448. > > 2) IIRC, the definition of "EC" talks about all defined curves having > "y", but not necressarily all curves having "y". Might be bad idea > implementation-wise to use that option however (I did encounter > comments about this pre-draft that indicated that options realistically > available are less than what JWK provodes). > > 3) I think it is a bad idea not to vary key fingerprint on algorithm. > However, that ship has already sailed. > > > -Ilari > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
