Subject: [jose] #53: Use "SEC1" format for elliptic curve keys

From: "jose issue tracker" <[email-masked]>
Date: Sun, 11 Aug 2013 22:54:33 -0000

#53: Use "SEC1" format for elliptic curve keys

 The "SEC1" format for elliptic curve points is used as the format for EC
 public keys in CMS, X.509, TLS, etc.  As a result, it enjoys widespread
 library support.

 * OpenSSL: "Note OpenSSL uses the private key format specified in 'SEC 1:
 Elliptic Curve Cryptography' (http://www.secg.org/)."
 * BouncyCastle: "[As of 2.39.3] EC Public/Private keys are now encoded in
 accordance with SEC 1."
 * CNG: CryptImportPublicKeyInfo uses SubjectPublicKeyInfo, which uses SEC1
 * PKCS#11: Uses IEEE P1363, which is the same as SEC1

 So rather than specifying an ad-hoc point format, we should re-use that
 format.  We could do this directly (by just having a binary field with the
 SEC1 encoding), or take the X and Y values defined in SEC1 and express
 them separately.

-- 
-------------------------+-------------------------------------------------
 Reporter:  [email-masked]   |      Owner:  draft-ietf-jose-json-web-
     Type:  defect       |  [email-masked]
 Priority:  major        |     Status:  new
Component:  json-web-    |  Milestone:
  algorithms             |    Version:
 Severity:  -            |   Keywords:
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/53>
jose <http://tools.ietf.org/jose/>

---

From: Brian Campbell <[email-masked]>
Date: Mon, 12 Aug 2013 15:11:08 -0600

-1

Ad-hoc as it might be, the current format is pretty simple and has
been working rather well for a good while now.

This would be a breaking change with no clear benefit.

On Sun, Aug 11, 2013 at 4:54 PM, jose issue tracker
<[email-masked]> wrote:
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Richard Barnes <[email-masked]>
Date: Mon, 12 Aug 2013 17:44:57 -0400

There are at least three clear benefits:

1. Compatibility with binary elliptic curves (e.g., the B-XXX curves in
FIPS 186)

2. Simplified compatibility with crypto libraries (as noted in the issue)

3. Space savings via compressed format

---

From: Richard Barnes <[email-masked]>
Date: Mon, 12 Aug 2013 17:47:18 -0400

Also:

4. Existing objects are not invalidated.  They're just prime curves,
non-compressed.

On Mon, Aug 12, 2013 at 5:44 PM, Richard Barnes <[email-masked]> wrote:

> On Mon, Aug 12, 2013 at 5:11 PM, Brian Campbell <
> [email-masked]> wrote:
>
>> -1
>>

---

From: Brian Campbell <[email-masked]>
Date: Wed, 14 Aug 2013 15:16:19 -0600

I can't say I've read all (or even much) of SEC 1 or that I understand
it but I don't how that's possible when the 1st paragraph of 2.3.3
(the section your patch references) says that the leftmost octet
indicates if compression is used or not.

On Mon, Aug 12, 2013 at 3:47 PM, Richard Barnes <[email-masked]> wrote:
>> <[email-masked]> wrote:
>>>
>>> -1
>>>

---

From: Richard Barnes <[email-masked]>
Date: Wed, 14 Aug 2013 21:53:07 -0400

If you read further into the patch, the proposal refers to the actual "X"
and "Y" values.  For reference:
Uncompressed = 0x04 || X || Y
Compressed = Y || X, where Y == 0x02 or 0x03

The proposal in the patch suggests that the JWK format just use the "X" and
"Y" values directly.  So the signaling of compressed/uncompressed would be
implicit; if x.length == y.length, uncompressed, else if y.length == 2
compressed (else fail).  For example:
Uncompressed: { "x": "ivc35sAmUfbHCpzKO1zSbsRgJBW29EEKQmD-4yULcAQ", "y":
"dd_jxUcjbqpGRWeP21qhE3ElPQrvFNpE8WuVweQQTtM" }
Compressed: { "x": "ivc35sAmUfbHCpzKO1zSbsRgJBW29EEKQmD-4yULcAQ", "y": "Aw"
}

So like I said, points in the current format would just be uncompressed
prime field points.

--Richard

On Wed, Aug 14, 2013 at 5:16 PM, Brian Campbell
<[email-masked]>wrote:

> >>> >  The "SEC1" format for elliptic curve points is used as the format
> for
> >>> > EC
> >>> >  * OpenSSL: "Note OpenSSL uses the private key format specified in
> 'SEC
> >>> > 1:
> >>> >  * BouncyCastle: "[As of 2.39.3] EC Public/Private keys are now
> encoded
> >>> > in
> >>> >  accordance with SEC 1."
> >>> >  * CNG: CryptImportPublicKeyInfo uses SubjectPublicKeyInfo, which
> uses
> >>> > SEC1
> >>> >  format.  We could do this directly (by just having a binary field
> with
> >>> > the

---

From: Brian Campbell <[email-masked]>
Date: Wed, 14 Aug 2013 21:10:19 -0600

To me anyway, that is not expressed clearly from the patch or the issue.

And I remain unconvinced of the value here.

On Wed, Aug 14, 2013 at 7:53 PM, Richard Barnes <[email-masked]> wrote:
> On Wed, Aug 14, 2013 at 5:16 PM, Brian Campbell <[email-masked]>
> wrote:
>>

---

From: Richard Barnes <[email-masked]>
Date: Thu, 15 Aug 2013 09:10:37 -0400

Ok, clarity we can work on.  How about a paragraph like this at the top of
level of the section "JWK Parameters for Elliptic Curve Public Keys", after
the origin paragraph:
"""
An elliptic curve point can be represented in compressed or uncompressed
format.  If the point is in uncompressed format, then both the "x" and "y"
values will represent elements of the base field.  In the compressed
format, the "x" value will be a field element, but the "y" value will be a
single-octet value indicating one of the two possible points with that "x"
value.

A recipient of a public key can determine whether a public key is
compressed or uncompressed by comparing the lengths of the "x" and "y"
fields.  If the two fields are of equal length, it is uncompressed; if the
"y" value has length 2, compressed.  If neither of these is the case (e.g.,
the "y" value has length 3), then the recipient MUST reject the key as
syntactically invalid.
"""

As far as value: Are you saying that we should not support binary curves,
or do you have a different idea of how points on those curves should be
represented?

On Wed, Aug 14, 2013 at 11:10 PM, Brian Campbell <[email-masked]

> >> >>> >  So rather than specifying an ad-hoc point format, we should
> re-use
> >> >>> > that

---

From: Russ Housley <[email-masked]>
Date: Thu, 15 Aug 2013 12:33:16 -0400

Richard:

The unclear IPR situation has caused many implementers to steer clear of compressed format.  So, ...

If we go down this path, support for uncompressed must be mandatory, and support for compressed must be optional.

Russ

On Aug 14, 2013, at 9:53 PM, Richard Barnes wrote:

> If you read further into the patch, the proposal refers to the actual "X" and "Y" values.  For reference:
> The proposal in the patch suggests that the JWK format just use the "X" and "Y" values directly.  So the signaling of compressed/uncompressed would be implicit; if x.length == y.length, uncompressed, else if y.length == 2 compressed (else fail).  For example:
> Uncompressed: { "x": "ivc35sAmUfbHCpzKO1zSbsRgJBW29EEKQmD-4yULcAQ", "y": "dd_jxUcjbqpGRWeP21qhE3ElPQrvFNpE8WuVweQQTtM" }
> Compressed: { "x": "ivc35sAmUfbHCpzKO1zSbsRgJBW29EEKQmD-4yULcAQ", "y": "Aw" }
> 
> So like I said, points in the current format would just be uncompressed prime field points.
> 
> --Richard
> 
> 
> 
> 
> 
> 
> On Wed, Aug 14, 2013 at 5:16 PM, Brian Campbell <[email-masked]> wrote:

---

From: Mike Jones <[email-masked]>
Date: Thu, 15 Aug 2013 16:32:24 +0000

I have an issue with the whole premise of "An elliptic curve point can be represented in compressed or uncompressed format".  Part of the design philosophy of JOSE/JWT has always been to have one simple way to do things whenever possible and to do them well.  Having multiple formats is a sure recipe for interop problems, because no matter what the spec says, some implementations will only implement the parts that they think they need at the time.

Thus, I'm against having two representations for elliptic curve keys.

                                             -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Thursday, August 15, 2013 6:11 AM
To: Brian Campbell
Cc: jose issue tracker; [email-masked]; [email-masked]
Subject: Re: [jose] #53: Use "SEC1" format for elliptic curve keys

Ok, clarity we can work on.  How about a paragraph like this at the top of level of the section "JWK Parameters for Elliptic Curve Public Keys", after the origin paragraph:
"""
An elliptic curve point can be represented in compressed or uncompressed format.  If the point is in uncompressed format, then both the "x" and "y" values will represent elements of the base field.  In the compressed format, the "x" value will be a field element, but the "y" value will be a single-octet value indicating one of the two possible points with that "x" value.

A recipient of a public key can determine whether a public key is compressed or uncompressed by comparing the lengths of the "x" and "y" fields.  If the two fields are of equal length, it is uncompressed; if the "y" value has length 2, compressed.  If neither of these is the case (e.g., the "y" value has length 3), then the recipient MUST reject the key as syntactically invalid.
"""

As far as value: Are you saying that we should not support binary curves, or do you have a different idea of how points on those curves should be represented?

On Wed, Aug 14, 2013 at 11:10 PM, Brian Campbell <[email-masked]<mailto:[email-masked]>> wrote:
To me anyway, that is not expressed clearly from the patch or the issue.

On Wed, Aug 14, 2013 at 7:53 PM, Richard Barnes <[email-masked]<mailto:[email-masked]>> wrote:
> On Wed, Aug 14, 2013 at 5:16 PM, Brian Campbell <[email-masked]<mailto:[email-masked]>>
> wrote:
>>
>> On Mon, Aug 12, 2013 at 3:47 PM, Richard Barnes <[email-masked]<mailto:[email-masked]>> wrote:
>> > Also:
>> >
>> > On Mon, Aug 12, 2013 at 5:44 PM, Richard Barnes <[email-masked]<mailto:[email-masked]>> wrote:
>> >>
>> >> <[email-masked]<mailto:[email-masked]>> wrote:
>> >>>
>> >>> -1
>> >>>
>> >>> <[email-masked]<mailto:[email-masked]>> wrote:
>> >>> >  Reporter:  [email-masked]<mailto:[email-masked]>   |      Owner:  draft-ietf-jose-json-web-
>> >>> >      Type:  defect       |  [email-masked]<mailto:[email-masked]>
>> >>> > [email-masked]<mailto:[email-masked]>

---

From: Richard Barnes <[email-masked]>
Date: Thu, 15 Aug 2013 12:40:38 -0400

I would be fine with removing the compressed format, and saying that the
points MUST use the uncompressed format.  This is doubleplusgood because it
means that current objects are completely unaffected.

I still think there's value in basing this in SEC1, since it gives us
binary curves.

On Thu, Aug 15, 2013 at 12:32 PM, Mike Jones <[email-masked]>wrote:

>  I have an issue with the whole premise of “An elliptic curve point can
> be represented in compressed or uncompressed format”.  Part of the design
> philosophy of JOSE/JWT has always been to have one simple way to do things
> whenever possible and to do them well.  Having multiple formats is a sure
> recipe for interop problems, because no matter what the spec says, some
> implementations will only implement the parts that they think they need at
> the time.****
>
> ** **
>
> Thus, I’m against having two representations for elliptic curve keys.****
>
> ** **
>
>                                              -- Mike****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Richard Barnes
> *Sent:* Thursday, August 15, 2013 6:11 AM
> *To:* Brian Campbell
> *Cc:* jose issue tracker; [email-masked];
> [email-masked]
> *Subject:* Re: [jose] #53: Use "SEC1" format for elliptic curve keys****
>
> ** **
>
> the origin paragraph:****
>
> """****
>
> value.****
> ** **
> syntactically invalid.****
>
> """****
>
> ** **
>
> represented?****
> ** **
> On Wed, Aug 14, 2013 at 11:10 PM, Brian Campbell <
> [email-masked]> wrote:****
>
> And I remain unconvinced of the value here.****
>
>
> >****
> ** **

---

From: Mike Jones <[email-masked]>
Date: Thu, 15 Aug 2013 16:51:46 +0000

So the current "crv", "x", "y" representation for the current EC curves would then remain unchanged?

Can you give us a proposed concrete representation example for a binary curve?

                                                            -- Mike

From: Richard Barnes [mailto:[email-masked]]
Sent: Thursday, August 15, 2013 9:41 AM
To: Mike Jones
Cc: Brian Campbell; [email-masked]
Subject: Re: [jose] #53: Use "SEC1" format for elliptic curve keys

I would be fine with removing the compressed format, and saying that the points MUST use the uncompressed format.  This is doubleplusgood because it means that current objects are completely unaffected.

I still think there's value in basing this in SEC1, since it gives us binary curves.

On Thu, Aug 15, 2013 at 12:32 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
I have an issue with the whole premise of "An elliptic curve point can be represented in compressed or uncompressed format".  Part of the design philosophy of JOSE/JWT has always been to have one simple way to do things whenever possible and to do them well.  Having multiple formats is a sure recipe for interop problems, because no matter what the spec says, some implementations will only implement the parts that they think they need at the time.

                                             -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Richard Barnes
Sent: Thursday, August 15, 2013 6:11 AM
To: Brian Campbell
Cc: jose issue tracker; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] #53: Use "SEC1" format for elliptic curve keys

---

From: Richard Barnes <[email-masked]>
Date: Thu, 15 Aug 2013 19:53:28 -0400

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 :)

<http://csrc.nist.gov/groups/ST/toolkit/documents/dss/NISTReCur.pdf>

On Thu, Aug 15, 2013 at 12:51 PM, Mike Jones <[email-masked]>wrote:

>  So the current “crv”, “x”, “y” representation for the current EC curves
> would then remain unchanged?****
>
> ** **
>
> Can you give us a proposed concrete representation example for a binary
> curve?****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *From:* Richard Barnes [mailto:[email-masked]]
> *Sent:* Thursday, August 15, 2013 9:41 AM
> *To:* Mike Jones
> *Cc:* Brian Campbell; [email-masked]
>
> means that current objects are completely unaffected.****
>
> ** **
>
> binary curves.  ****
> On Thu, Aug 15, 2013 at 12:32 PM, Mike Jones <[email-masked]>
> wrote:****
>
> I have an issue with the whole premise of “An elliptic curve point can be
> represented in compressed or uncompressed format”.  Part of the design

---

From: Mike Jones <[email-masked]>
Date: Fri, 16 Aug 2013 00:09:43 +0000

Maybe this seems too easy to me because I misunderstand something, but from your example, the only open question that seems to remain about this issue is whether to register "crv" values other than "P-256", "P-384", and "P-521".  To me, this would only seem to make sense if they are actually used in practice.

Given that the Suite B Implementer's Guide to NIST SP 800-56A (http://www.nsa.gov/ia/_files/SuiteB_Implementer_G-113808.pdf) doesn't include any curves outside that set, I question whether other curves are frequently enough used to warrant inclusion in our standard set.

                                                                -- Mike

From: Richard Barnes [mailto:[email-masked]]
Sent: Thursday, August 15, 2013 4:53 PM
To: Mike Jones
Cc: Brian Campbell; [email-masked]
Subject: Re: [jose] #53: Use "SEC1" format for elliptic curve keys

{
  "kty": "EC",
  "crv": "B-283",

No special magic, just base64url-encoding an octet string.  But it's important that you use the *right* octet string :)

On Thu, Aug 15, 2013 at 12:51 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
So the current "crv", "x", "y" representation for the current EC curves would then remain unchanged?

                                                            -- Mike

From: Richard Barnes [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, August 15, 2013 9:41 AM
To: Mike Jones
Cc: Brian Campbell; [email-masked]<mailto:[email-masked]>

                                             -- Mike

---

From: Richard Barnes <[email-masked]>
Date: Thu, 15 Aug 2013 22:28:08 -0400

The point format question isn't about specific curves, it's whether we want
to support binary curves at all.  The current format just doesn't define a
way to represent binary curve points, so they can't be used.  Referencing
SEC1/uncompressed would mean no change for current (prime) curves, but
would add support for binary curves.

While prime curves do seem more popular, there are a fair number of binary
curves out there.  The relevant NIST spec (186-4) arguably recommends more
binary than prime curves.  See appendix D of:
http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf

So this seems like a low-cost change, without which we lose significant
capability.

On Thursday, August 15, 2013, Mike Jones wrote:

>  Maybe this seems too easy to me because I misunderstand something, but
> from your example, the only open question that seems to remain about this
> issue is whether to register “crv” values other than “P-256”, “P-384”, and
> “P-521”.  To me, this would only seem to make sense if they are actually
> used in practice.****
>
> ** **
>
> Given that the Suite B Implementer’s Guide to NIST SP 800-56A (
> http://www.nsa.gov/ia/_files/SuiteB_Implementer_G-113808.pdf) doesn’t
> include any curves outside that set, I question whether other curves are
> frequently enough used to warrant inclusion in our standard set.****
>
> ** **
>
>                                                                 -- Mike***
> *
>
> ** **
>
> *From:* Richard Barnes [mailto:[email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');>]
> *Sent:* Thursday, August 15, 2013 4:53 PM
> *To:* Mike Jones
> *Cc:* Brian Campbell; [email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');>
> The base point of the NIST curve B-283 would be:****
>
> ** **
>
> {****
>
>   "kty": "EC",****
>
>   "crv": "B-283",****
>
>   "x": "Bfk5JY233ZDhk0-McLDf7C7tJbhVfqycgOLhmPjNvs2GsSBT",****
>
>   "y": "A2doVP4kFBy5j-bUsg0CtFFv9wI1Dt2wgmd5yBPw30W-gRL0",****
>
> } ****
>
> ** **
>
> important that you use the *right* octet string :)****
>
> ** **
>
> <http://csrc.nist.gov/groups/ST/toolkit/documents/dss/NISTReCur.pdf>****
>
> ** **
>
> On Thu, Aug 15, 2013 at 12:51 PM, Mike Jones <[email-masked]>
> wrote:****
>
> *Cc:* Brian Campbell; [email-masked]****
>
>

---

From: John Bradley <[email-masked]>
Date: Thu, 15 Aug 2013 22:31:35 -0400

Binary fields tend to be used more in embedded hardware for power and performance reasons.  (binary fields = less gates)

That may or may not remain the case.  

While I don't see a real advantage to having JOSE require implementations to support those curves and the different logic to process them, it may make sense for JWK to support those additional types for non JOSE applications.  

With the onset of the internet of things where EC over binary fields becomes more important for dedicated hardware, there may come an argument that in order to interoperate with low power devices JOSE may need to support binary curves.   I think that may be a bit premature to jump to the conclusion that current generation constrained environments prefer binary fields.

So in general Mike is correct that in software implementations prime fields are much more common.

John B.

On 2013-08-15, at 8:09 PM, Mike Jones <[email-masked]> wrote:

> Maybe this seems too easy to me because I misunderstand something, but from your example, the only open question that seems to remain about this issue is whether to register “crv” values other than “P-256”, “P-384”, and “P-521”.  To me, this would only seem to make sense if they are actually used in practice.
>  
> Given that the Suite B Implementer’s Guide to NIST SP 800-56A (http://www.nsa.gov/ia/_files/SuiteB_Implementer_G-113808.pdf) doesn’t include any curves outside that set, I question whether other curves are frequently enough used to warrant inclusion in our standard set.
>  
>                                                                 -- Mike
>  
> On Thu, Aug 15, 2013 at 12:51 PM, Mike Jones <[email-masked]> wrote:
> So the current “crv”, “x”, “y” representation for the current EC curves would then remain unchanged?
>  
> On Thu, Aug 15, 2013 at 12:32 PM, Mike Jones <[email-masked]> wrote:
> I have an issue with the whole premise of “An elliptic curve point can be represented in compressed or uncompressed format”.  Part of the design philosophy of JOSE/JWT has always been to have one simple way to do things whenever possible and to do them well.  Having multiple formats is a sure recipe for interop problems, because no matter what the spec says, some implementations will only implement the parts that they think they need at the time.
>  
> Thus, I’m against having two representations for elliptic curve keys.
>  
>                                              -- Mike
>  
> On Wed, Aug 14, 2013 at 11:10 PM, Brian Campbell <[email-masked]> wrote:

---

From: Russ Housley <[email-masked]>
Date: Fri, 16 Aug 2013 13:40:44 -0400

> 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

---

From: Richard Barnes <[email-masked]>
Date: Fri, 16 Aug 2013 14:12:32 -0400

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-masked]> wrote:

> 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
>
>
>

---

From: Mike Jones <[email-masked]>
Date: Fri, 16 Aug 2013 20:51:20 +0000

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:

{
  "kty": "EC",
  "crv": "B-283",

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-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Friday, August 16, 2013 11:13 AM
To: Russ Housley
Cc: [email-masked]
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-masked]<mailto:[email-masked]>> wrote:
Richard:

Russ

---

From: Richard Barnes <[email-masked]>
Date: Fri, 16 Aug 2013 18:00:13 -0400

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-masked]>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:****
>
> ** **
>
> 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****
>
> ** **
>
> *Sent:* Friday, August 16, 2013 11:13 AM
> *To:* Russ Housley
> *Cc:* [email-masked]
>
> to add a binary curve, the current format is insufficient.****
>
> ** **
>
> On Fri, Aug 16, 2013 at 1:40 PM, Russ Housley <[email-masked]>
> wrote:****
>
> Richard:****
>
>
>
> ****
>
> binary curves.****
> I do not know if you are advocating every aspect of SEC1 or not.****
>
> ** **
>
> for a jose identifier.****
>
> ** **
>
> Russ****
>
> ** **
>
> ** **
>
> ** **
>