(For Java) the asymmetric.ec.SignatureSpi implementation for

{varioushashes}withCVC-ECDSA, aliased as PLAIN-ECDSA, use

PlainDSAEncoder which concatenates r and s each expressed as unsigned

(bigendian) both with the same size which is the larger of the

two. If both r and s are sufficiently smaller than the group order,

that chosen size is smaller than the size of the group order. On

curves like P-256 and P-384, whose order is very close to 256 or 384

bits, having r and s both that small will be rare, but for P-521 aka

secp521r1 it happens for about 25% of signatures.

I think this is wrong, or at least unconventional.

https://www.bouncycastle.org/specifications.html (found by searching

but not linked anywhere I could find?) doesn't list these signature

schemes at all, much less specify the encoding for either the usual

ASN.1 (X9.62/SEC1) versions or the 'plain' versions. The release notes

section for 1.51 calls it 'BSI plain ECDSA'. Guessing that means BSI

TR-03111, that says (5.2.1) to concatenate "R = I2OS(r; l) and S =

I2OS(s; l) with l = ceil(log256 n)" where 'l' the second argument to

I2OS is the required length, and 'n' is the group order, i.e. the

order of the basepoint on the curve. (Since P-521 was chosen with

cofactor 1, the group/point order is the same as the curve order, but

that is not true in general. For P-521 ceil(log256 n) is 66.)

I believe P1363 says the same, but don't have money to check. XMLDSIG

definitely does, at

https://tools.ietf.org/html/rfc6931#section-2.3.6
The output of the ECDSA algorithm consists of a pair of integers

usually referred by the pair (r, s). The signature value consists of

the base64 encoding of the concatenation of two octet streams that

respectively result from the octet-encoding of the values r and s in

that order. Conversion from integer to octet stream must be done

according to the I2OSP operation defined in the [RFC3447]

specification with the l parameter equal to the size of the base

point order of the curve in bytes (e.g., 32 for the P-256 curve and

66 for the P-521 curve [FIPS186-3]).

(186-3 is a reference for the curves, but not the encoding.)

The previous version

https://tools.ietf.org/html/rfc4050#section-3.3referenced P1363 (2000) which I take as fairly strong confirmation

that P1363 is the same, since 6931 shouldn't have made an incompatible

change without at least warning about it.

Cheers. -

[hidden email]