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
