It sounds to me like your approach is the best behavior for an implementation. Postel's law and all.
On Thu, Feb 13, 2014 at 2: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
