Subject: Re: [jose] question about the size of coordinate parameters in EC JWKs

From: Mike Jones <[email-masked]>
Date: Thu, 13 Feb 2014 07:39:36 +0000

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 xP 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 Fq.
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.2 and 6.2.1.3.

                                                            -- Mike

From: jose [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Wednesday, February 12, 2014 5:50 PM
To: 'Richard Barnes'; 'Brian Campbell'
Cc: [email-masked]<mailto:[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]] On Behalf Of Richard Barnes
Sent: Wednesday, February 12, 2014 4:28 PM
To: Brian Campbell
Cc: [email-masked]<mailto:[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]<mailto:[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]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose

---

From: Richard Barnes <[email-masked]>
Date: Thu, 13 Feb 2014 10:45:28 -0500

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
>
> *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
>
>
>
> *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.
>
> [1]
> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-20#section-6.2
>
>
> [email-masked]

---

From: Brian Campbell <[email-masked]>
Date: Thu, 13 Feb 2014 12:59:44 -0700

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:

>> *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
>>
>>
>>
>> *Subject:* Re: [jose] question about the size of coordinate parameters
>> in EC JWKs
>>
>>
>>

---

From: Richard Barnes <[email-masked]>
Date: Thu, 13 Feb 2014 15:33:01 -0500

It sounds to me like your approach is the best behavior for an
implementation.  Postel's law and all.

---

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

Once I fix the output to conform to the MUST in the spec, I agree with you
:) But yes, in honor of Postel, I'll leave it so that it'll still accept
either way as input.

Thanks, by the way, for your replies to this thread.

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

> On Thu, Feb 13, 2014 at 2: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
>>>>
>>>>
>>>>