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
