Once again, this reply confuses me. I thought that you demonstrated through
your example that we could represent binary curve keys using the existing
format by using a different curve parameter:
The base point of the NIST curve B-283 would be:
{
"kty": "EC",
"crv": "B-283",
"x": "Bfk5JY233ZDhk0-McLDf7C7tJbhVfqycgOLhmPjNvs2GsSBT",
"y": "A2doVP4kFBy5j-bUsg0CtFFv9wI1Dt2wgmd5yBPw30W-gRL0",
}
No special magic, just base64url-encoding an octet string. But it's important
that you use the *right* octet string :)
So it doesn't seem that we've locked ourselves out of representing binary
curves in any manner. To add them at some point, we just need to register
additional "crv" values.
-- Mike
From: [email protected] [mailto:[email protected]] On Behalf Of Richard
Barnes
Sent: Friday, August 16, 2013 11:13 AM
To: Russ Housley
Cc: [email protected]
Subject: Re: [jose] #53: Use "SEC1" format for elliptic curve keys
I'm not saying we need to add any curves in particular, just that we shouldn't
lock ourselves out of binary curves altogether. If we ever want to add a
binary curve, the current format is insufficient.
On Fri, Aug 16, 2013 at 1:40 PM, Russ Housley
<[email protected]<mailto:[email protected]>> wrote:
Richard:
I still think there's value in basing this in SEC1, since it gives us binary
curves.
I do not know if you are advocating every aspect of SEC1 or not.
Experience to date has shown that support for arbitrary curves does not get
implemented. For this reason, we have been focusing on well-known curves such
as the NIST curves and the Brainpool curves. An identifier is sufficient to
provide all of the curve parameters. The SEC1 format supports this using an
object identifier. That seems like the wrong form for a jose identifier.
Russ
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
