[rootvector2]

ECDSAEncoder.toX962 reads the ITS signature's r without checking which EccP256CurvePoint or EccP384CurvePoint choice carried it, so a signature re-encoded with rSig as compressed-y-0 or compressed-y-1 (the same 32 x octets) yields an identical r and still verifies, giving one signature three interchangeable encodings and letting a re-encoded certificate keep verifying under a different HashedId8, while the fill and uncompressed choices escape signatureValid and isSignatureValid as an unchecked IllegalArgumentException; found checking the IEEE 1609.2 sec. 6.3.29 x-only requirement against the decoder, and r is now required to be of form x-only in both branches.

AI tooling was used to help prepare this change.

[dghgit]

Thanks for the report, merged with revisions.

The issue was IEEE 1609.2 doesn't restrict rSig to x-only. The EcdsaP256Signature / EcdsaP384Signature text says x-only is used when the signer outputs the integer r. When the signer outputs the point R, it is carried as compressed-y-0, compressed-y-1 or uncompressed "at the sender's discretion". Rejecting those forms would refuse conformant signatures.

On the other hand, the HashedId8 problem you found is real. The fix belongs where the standard puts it: "If hashing, theEccP256CurvePoint in rSig shall be taken to be of form x-only." ITSCertificate.getCanonicalEncoding() now does this, and every place that hashes a certificate uses it. A re-encoded, rSig therefore no longer changes a certificate's HashedId8.