[Bug 27602] ECDSA's Sign operation is not explicit about how r and s are concatenated (padding)

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27602

--- Comment #2 from Eric Roman <ericroman@google.com> ---
Yes, that is along the lines of what I was thinking.

To copy some language from the JWA spec [1] as an example, it says this about
ECDSA (P-256):

"
   2.  Turn R and S into octet sequences in big endian order, with each
       array being be 32 octets long.  The octet sequence
       representations MUST NOT be shortened to omit any leading zero
       octets contained in the values.

   3.  Concatenate the two octet sequences in the order R and then S.
"

Except instead of "32 octets" we would say something more general like (also
from JWA):

  "ceiling(log-base-2(n)/8) octets (where n is the order of the curve)"



My primary concern for compatibility is being explicit that the leading zeros
are mandatory.

Otherwise we could have implementations for which it is sufficient that len(r)
== len(s), and not the stronger requirement that len(r) == len(s) ==
ceiling(log-base-2(n)/8).

Cheers.

[1]
https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-39#section-6.2.1

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Wednesday, 7 January 2015 02:18:29 UTC