This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The spec says the following: --------------------- 2. Let r and s be the pair of integers resulting from performing the ECDSA signing process. 3. Let result be a new ArrayBuffer. 4. Convert r to a bitstring and append the sequence of bytes to result. 5. Convert s to a bitstring and append the sequence of bytes to result. --------------------- As I understand "r" and "s" are big integers in big-endian order. Prior to concatenation r and s must be padded to a fixed length, otherwise when reversing the process during verify() it is unclear unclear how to extract r and s. I believe they should be zero-padded to the group order size in bytes.
r and s are just integers in the interval [ 1, n-1 ] where n is the order of the base point G of the elliptic curve. The ambiguity is in "Convert r/s to a bitstring" since it is not specified what the output bitstring length should be. I assume it should be the smallest multiple of 8 bits which can represent the value n-1 (I expect this is also what Eric meant in comment #0).
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
Moved to https://github.com/w3c/webcrypto/issues/65