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 xP 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 Fq.
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.2
and 6.2.1.3.
-- Mike
From: jose [mailto:[email protected]] On Behalf Of Jim Schaad
Sent: Wednesday, February 12, 2014 5:50 PM
To: 'Richard Barnes'; 'Brian Campbell'
Cc: [email protected]<mailto:[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]] On Behalf Of Richard Barnes
Sent: Wednesday, February 12, 2014 4:28 PM
To: Brian Campbell
Cc: [email protected]<mailto:[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
