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 protected]>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. > > 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 protected]> 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 protected]> wrote: >> >>> Consistency with SEC1 seems like a compelling enough argument to me. >>> >>> >>> On Thu, Feb 13, 2014 at 2:39 AM, Mike Jones <[email protected] >>> > 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 protected]] *On Behalf Of *Mike Jones >>>> *Sent:* Wednesday, February 12, 2014 11:29 PM >>>> *To:* Jim Schaad; 'Richard Barnes'; 'Brian Campbell' >>>> >>>> *Cc:* [email protected] >>>> *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 protected] <[email protected]>] *On >>>> Behalf Of *Jim Schaad >>>> *Sent:* Wednesday, February 12, 2014 5:50 PM >>>> *To:* 'Richard Barnes'; 'Brian Campbell' >>>> *Cc:* [email protected] >>>> *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 protected] <[email protected]>] *On >>>> Behalf Of *Richard Barnes >>>> *Sent:* Wednesday, February 12, 2014 4:28 PM >>>> *To:* Brian Campbell >>>> *Cc:* [email protected] >>>> *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 protected]> 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 protected] >>>> https://www.ietf.org/mailman/listinfo/jose >>>> >>>> >>>> >>> >>> >> > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
