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
