Subject: [jose] ECC Private Key (was Re: question about the size of coordinate parameters in EC JWKs)

From: Brian Campbell <[email-masked]>
Date: Thu, 13 Feb 2014 14:03:50 -0700

Somewhat related, could anyone be so kind as to try and explain in somewhat
more plain English what's meant by the definition of the ECC Private Key
Parameter d (text from JWA 6.2.2.1 copied below)? As well as how and why
it's different than the x and y representations.

My implementation is (maybe naively) doing the same thing to convert d as
it does for x and y. Which is what it was doing before the SEC1 references
were introduced to the draft. I remember being assured that SEC1 usage
wasn't a breaking change. When I read the text in 6.2.2.1, I'm not totally
confident with things.

Maybe it's a moral failing on my part but I find SEC1 a little hard to
read. C.4, for example, has version and parameters and public key that I
think should be ignored in the JWK/A context but I'm not sure.

As always, I appreciate any help or guidance folks can provide.

"6.2.2.1.  "d" (ECC Private Key) Parameter

   The "d" (ECC private key) member contains the Elliptic Curve private
   key value.  It is represented as the base64url encoding of the octet
   string representation of the private key value, as defined in
   Sections C.4 and 2.3.7 of SEC1 [SEC1].  The length of this octet
   string MUST be ceiling(log-base-2(n)/8) octets (where n is the order
   of the curve)."  - from
http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-20#section-6.2.2.1

On Thu, Feb 13, 2014 at 12:59 PM, Brian Campbell <[email-masked]
> wrote:

> I wasn't necessarily looking to make a change. Though interoperability is
> in sometimes in the eye of the beholder. Yes, I realize it's a defect but
> my implementation currently emits the coordinate value omitting the left
> zero padding bytes but will accept either input. So the MAY that Richard
> proposed would likely improve interoperability for me. It's not a hill I
> want to die on though so I'll zero-pad some arrays in my implementation.
>
>
> On Thu, Feb 13, 2014 at 8:45 AM, Richard Barnes <[email-masked]> wrote:
>
>> Consistency with SEC1 seems like a compelling enough argument to me.
>>
>>
>> On Thu, Feb 13, 2014 at 2:39 AM, Mike Jones <[email-masked]>wrote:
>>
>>>  I'll also add that SEC1 (http://www.secg.org/collateral/sec1_final.pdf)
>>> requires that the full octet string be present, and we decided to base our
>>> representation on SEC1.  For instance, SEC1 says:
>>>
>>>
>>>
>>> 2.1. Convert the field element * x**P *to an octet string *X *of length
>>> ceiling(log2 *q*/8) octets using the conversion
>>>
>>> routine specified in Section 2.3.5.
>>>
>>>
>>>
>>> and in SEC1 2.3.5:
>>>
>>>
>>>
>>> *Input: *An element *a * of the field F*q*.
>>>
>>> *Output: *An octet string *M *of length *mlen* = ceiling(log2 *q*/8)
>>> octets.
>>>
>>>
>>>
>>> There's no compelling reason to special-case the situation in which some
>>> of the leading bits in the field element are zeros.
>>>
>>>
>>>
>>>                                                             -- Mike
>>>
>>>
>>>
>>> *From:* jose [mailto:[email-masked]] *On Behalf Of *Mike Jones
>>> *Sent:* Wednesday, February 12, 2014 11:29 PM
>>> *To:* Jim Schaad; 'Richard Barnes'; 'Brian Campbell'
>>>
>>> *Cc:* [email-masked]
>>> *Subject:* Re: [jose] question about the size of coordinate parameters
>>> in EC JWKs
>>>
>>>
>>>
>>> Sure.  See
>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-20#section-6.2.1.2and 6.2.1.3.
>>>
>>>
>>>
>>>                                                             -- Mike
>>>
>>>
>>>
>>> *From:* jose [mailto:[email-masked] <[email-masked]>] *On
>>> Behalf Of *Jim Schaad
>>> *Sent:* Wednesday, February 12, 2014 5:50 PM
>>> *To:* 'Richard Barnes'; 'Brian Campbell'
>>> *Cc:* [email-masked]
>>> *Subject:* Re: [jose] question about the size of coordinate parameters
>>> in EC JWKs
>>>
>>>
>>>
>>> Would it be possible for somebody to give me a better reference pointer
>>> to the document that is begin reference?
>>>
>>>
>>>
>>> *From:* jose [mailto:[email-masked] <[email-masked]>] *On
>>> Behalf Of *Richard Barnes
>>> *Sent:* Wednesday, February 12, 2014 4:28 PM
>>> *To:* Brian Campbell
>>> *Cc:* [email-masked]
>>> *Subject:* Re: [jose] question about the size of coordinate parameters
>>> in EC JWKs
>>>
>>>
>>>
>>> That would make sense only for binary curves, but most of the curves
>>> people use today are integer curves, in which case truncation is totally
>>> sensible.
>>>
>>>
>>>
>>> I've been told that some Microsoft crypto libraries use fixed-length
>>> buffers for these things, but there should be a problem copying a shorter
>>> value into that buffer.
>>>
>>>
>>>
>>> Net of that, I would be in favor of saying that the coordinates MUST be
>>> full-length for binary curves, and MAY be zero-padded to full length for
>>> integer curves.
>>>
>>>
>>>
>>> --Richard
>>>
>>>
>>>
>>> On Wed, Feb 12, 2014 at 6:58 PM, Brian Campbell <
>>> [email-masked]> wrote:
>>>
>>> Could anyone in this fine WG explain (probably again, I missed it the
>>> first time) the rational behind the text 'The length of this octet string
>>> MUST be the full size of a coordinate for the curve specified in the "crv"
>>> parameter.', which is in the definitions of the X and Y Coordinate
>>> parameters for EC keys in JWA [1]?
>>>
>>> This message last month on the list
>>> http://www.ietf.org/mail-archive/web/jose/current/msg03901.html and an
>>> off list message indicate that both the jose4j and Nimbus JOSE+JWT
>>> implementations aren't following spec on the length of the octet string
>>> being the full size of a coordinate for the curve. Which suggests that
>>> there maybe potential interoperability problems with certain EC JWKs.
>>>
>>> I'm just trying to wrap my head around the issue so any help in that
>>> would be appreciated.
>>>
>>>
>>> [1]
>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-20#section-6.2
>>>
>>>
>>> _______________________________________________
>>> jose mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/jose
>>>
>>>
>>>
>>
>>
>

---

From: Richard Barnes <[email-masked]>
Date: Thu, 13 Feb 2014 16:23:26 -0500

In plain English: "d" is always an integer, while "x" and "y" can be more
exotic things.

So in practice, it depends on the type of the curve.  For "integer" curves,
"x", "y", and "d" are all integers, and you can treat them the same.  For
"binary" curves, "x" and "y" are different.  IIRC, though, all of the
curves we have defined right now are integer curves.

On Thu, Feb 13, 2014 at 4:03 PM, Brian Campbell
<[email-masked]>wrote:

> Somewhat related, could anyone be so kind as to try and explain in
> somewhat more plain English what's meant by the definition of the ECC
> Private Key Parameter d (text from JWA 6.2.2.1 copied below)? As well as
> how and why it's different than the x and y representations.
>
> On Thu, Feb 13, 2014 at 12:59 PM, Brian Campbell <
>>> On Thu, Feb 13, 2014 at 2:39 AM, Mike Jones <[email-masked]
>>> > wrote:
>>>
>>>> 2.1. Convert the field element * x**P *to an octet string *X *of
>>>> length ceiling(log2 *q*/8) octets using the conversion
>>>>
>>>> There's no compelling reason to special-case the situation in which
>>>> some of the leading bits in the field element are zeros.
>>>>
>>>>
>>>>
>>>>                                                             -- Mike
>>>>
>>>>
>>>>

---

From: Brian Campbell <[email-masked]>
Date: Thu, 13 Feb 2014 14:48:56 -0700

Thank you Richard (again). And yes, all of the curves we have defined right
now are integer curves.

On Thu, Feb 13, 2014 at 2:23 PM, Richard Barnes <[email-masked]> wrote:

> So in practice, it depends on the type of the curve.  For "integer"
> curves, "x", "y", and "d" are all integers, and you can treat them the
> same.  For "binary" curves, "x" and "y" are different.  IIRC, though, all
> of the curves we have defined right now are integer curves.
>
>
> On Thu, Feb 13, 2014 at 4:03 PM, Brian Campbell <
>>> I wasn't necessarily looking to make a change. Though interoperability
>>> is in sometimes in the eye of the beholder. Yes, I realize it's a defect
>>> but my implementation currently emits the coordinate value omitting the
>>> left zero padding bytes but will accept either input. So the MAY that
>>> Richard proposed would likely improve interoperability for me. It's not a
>>> hill I want to die on though so I'll zero-pad some arrays in my
>>> implementation.
>>>
>>>
>>>> On Thu, Feb 13, 2014 at 2:39 AM, Mike Jones <
>>>> [email-masked]> wrote:
>>>>
>>>>>  I'll also add that SEC1 (
>>>>> http://www.secg.org/collateral/sec1_final.pdf) requires that the full
>>>>> octet string be present, and we decided to base our representation on
>>>>> SEC1.  For instance, SEC1 says:
>>>>>
>>>>>
>>>>>
>>>>> *Subject:* Re: [jose] question about the size of coordinate
>>>>> parameters in EC JWKs
>>>>>
>>>>>
>>>>>
>>>>> Sure.  See
>>>>> *Subject:* Re: [jose] question about the size of coordinate
>>>>> parameters in EC JWKs
>>>>>
>>>>>
>>>>>
>>>>> Would it be possible for somebody to give me a better reference
>>>>> pointer to the document that is begin reference?
>>>>>
>>>>>
>>>>>
>>>>> *Subject:* Re: [jose] question about the size of coordinate
>>>>> parameters in EC JWKs
>>>>>
>>>>>
>>>>>
>>>>> Net of that, I would be in favor of saying that the coordinates MUST
>>>>> be full-length for binary curves, and MAY be zero-padded to full length for
>>>>> integer curves.
>>>>>
>>>>>
>>>>>
>>>>> --Richard
>>>>>
>>>>>
>>>>>
>>>>> http://www.ietf.org/mail-archive/web/jose/current/msg03901.html and
>>>>> an off list message indicate that both the jose4j and Nimbus JOSE+JWT