shouldn't cvc/plain-ecdsa encode to group size?

(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.3
referenced 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. - [email protected]