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