The example demonstrates how you would do it if (1) we had a point format
that used SEC1 to describe how to encode binary points, and (2) we had an
identifier for "B-283". The latter is the easy one, but it's also not what
I'm advocating here.
Right now, it is not at all clear to an implementor how a binary field
element (a coordinate for a point on a binary curve) should be represented.
There are pretty much two ways to represent an integer in binary (little
or big endian), and we've chosen one of those. It's not like that for
binary fields. There are multiple equivalent representations for an
element of a binary field, and arithmetic is easier or harder to do in
different representations. For example, the same NIST document from which
I pulled the above example defines two different ways to represent field
elements ("polynomial" and "normal"), and conversion between them.
In order to have an interoperable support for binary fields, you need to
fix a representation for field elements. The point of referring to SEC1 is
that it fixes a representation for both integers (which happens to be the
same as what we already have) and for binary field elements. And it does
it the same way as everyone else has.
On Fri, Aug 16, 2013 at 4:51 PM, Mike Jones <[email protected]>wrote:
> 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]>
> 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
