The MAY would result in interop problems, since some implementations would
correctly handle short values and some wouldn't. It's the way it is so that
there's a consistent and unambiguous rule. And it's not hard to implement
(especially when using underlying libraries, such as the ones that Richard
cites, that already provide fixed-length representations of these values). If
you're using a library with variable-length value representations, just zero
the whole array and copy the bytes provided in a right-justified manner into
the array.
I really don't think we should add conditionals that implementations would have
to handle here, as they could only hurt interop.
-- Mike
From: jose [mailto:[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]<mailto:[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]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
