Hi, I found one more problem around the ECDSA test files.
For example, tests/aleksey-xmldsig-01/enveloping-sha256-ecdsa-sha256.xml has a <SignatureValue> that is of 64 bytes after base64 decode. However, when I tried to test the signature verifier with other ECDSA testcases, the signature value was longer. Example: The last attachment to <https://bugs.documentfoundation.org/show_bug.cgi?id=105983> has a signature that looks like this: <SignatureValue xmlns="http://www.w3.org/2000/09/xmldsig#"; Id="SignatureValue_4513a8b22f16c956d127c7844419ed2b006635af4e855d7f1d06ea9d49e4e8af">MEQCIHpA2WCOXQ5z7qcmtIU+LiPgh3WBUBga7Ny0sZ8Jh9FhAiB0Mr6G+9zMTmkuOOeVZmwuIcQjcSm5SPg+Gfi0T7cdcw==</SignatureValue> i.e. it's 70 bytes after base64 decode: it's 2 integers of 32 bytes, but it's ASN1 encoded. This difference made me curious: which one is incorrect? As far as I see this is specified in https://www.ietf.org/rfc/rfc3279.txt, section "2.2.3 ECDSA Signature Algorithm". It says: "To easily transfer these two values as one signature, they MUST be ASN.1 encoded using the following ASN.1 structure: Ecdsa-Sig-Value ::= SEQUENCE { r INTEGER, s INTEGER }" So to me, it looks like: - the xmlsec openssl backend doesn't do this encoding, even if it's a must according to the RFC - the test file tests this bad behavior - because i used the test files as a reference for the behavior, now I implemented the same in the nss backend as well Would it be OK if I change (send a pull request that changes) the test files to contain this required ASN1 encoding? Fixing the NSS backend is easy to read/write the encoded form, I can do that. I can also try to fix the openssl backend to conform to the RFC. Thanks, Miklos
signature.asc
Description: Digital signature
_______________________________________________ xmlsec mailing list [email protected] http://www.aleksey.com/mailman/listinfo/xmlsec
