[xmlsec] ECDSA test key/files

[Miklos Vajna]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20170304/d29db06e/attachment.sig>