Santuario
  1. Santuario
  2. SANTUARIO-266

c14n11 produces different signatures using version 1.4.3 and 1.4.4

    Details

      Description

      When I changed the canonicalization algorithm used to generate signatures from "http://www.w3.org/TR/2001/REC-xml-c14n-20010315" to "http://www.w3.org/2006/12/xml-c14n11" and the version of Santuario from 1.4.3 to 1.4.4 all the signatures produced were no more valid if verified by the version 1.4.3 and viceversa.

      I mean that "http://www.w3.org/TR/2001/REC-xml-c14n-20010315" produces the same signature in both versions, while "http://www.w3.org/2006/12/xml-c14n11" has the following beaviour:
      1) SignatureValue differs
      2) the SignedInfo used to produce the signature is:
      1.4.3
      <ds:SignedInfo xmlns:apache="http://www.apache.org/ns/#app1" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:foo="http://example.org/#foo">
      1.4.4
      <ds:SignedInfo attr1="test1" foo:attr1="foo's test" id="testId" xmlns:apache="http://www.apache.org/ns/#app1" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:foo="http://example.org/#foo">

      The document before the signature is:
      <apache:RootElement xmlns:apache="http://www.apache.org/ns/#app1" xmlns:foo="http://example.org/#foo" attr1="test1" id="testId" foo:attr1="foo's test">Some simple text
      </apache:RootElement>

      To create a sample to reproduce the issue I modified https://svn.apache.org/repos/asf/santuario/xml-security-java/trunk/samples/org/apache/xml/security/samples/signature/CreateSignature.java using an RSA key (to generate the same SignatureValue each time).
      Obviously, I can't write a JUnit because you need two different versions of Santuario's library.

      1. xmlsec-1.4.5-SNAPSHOT.jar
        440 kB
        Colm O hEigeartaigh
      2. test144.xml
        3 kB
        Giacomo Boccardo
      3. test143.xml
        3 kB
        Giacomo Boccardo
      4. TestGenEnvelopedTutorial.java
        7 kB
        Giacomo Boccardo

        Activity

        Hide
        Giacomo Boccardo added a comment -

        Not a "real" JUnit: to be executed with Santuario's versions 1.4.3 and 1.4.4.

        Show
        Giacomo Boccardo added a comment - Not a "real" JUnit: to be executed with Santuario's versions 1.4.3 and 1.4.4.
        Hide
        Gabriele Contini added a comment -

        This could be a duplicate of https://issues.apache.org/jira/browse/SANTUARIO-191 because the "apache:RootElement" node has an attribute Id that in version 1.4.4 is attached to the SignedInfo structure.

        Show
        Gabriele Contini added a comment - This could be a duplicate of https://issues.apache.org/jira/browse/SANTUARIO-191 because the "apache:RootElement" node has an attribute Id that in version 1.4.4 is attached to the SignedInfo structure.
        Hide
        Colm O hEigeartaigh added a comment -

        I'll take a look. It's definately not a duplicate of SANTUARIO-191, as that issue has been fixed. Perhaps the fix has introduced this regression.

        Colm.

        Show
        Colm O hEigeartaigh added a comment - I'll take a look. It's definately not a duplicate of SANTUARIO-191 , as that issue has been fixed. Perhaps the fix has introduced this regression. Colm.
        Hide
        Colm O hEigeartaigh added a comment -

        Are you sure this is a bug? As I said in the previous comment, there was a bug in 1.4.3 (see SANTUARIO-191) that has been fixed in 1.4.4. It's entirely possible the signature that was generated in 1.4.3 was incorrect.

        Colm.

        Show
        Colm O hEigeartaigh added a comment - Are you sure this is a bug? As I said in the previous comment, there was a bug in 1.4.3 (see SANTUARIO-191 ) that has been fixed in 1.4.4. It's entirely possible the signature that was generated in 1.4.3 was incorrect. Colm.
        Hide
        Giacomo Boccardo added a comment - - edited

        I attached two files (test14

        {3|4}

        .xml) generated signing the same document using the two different versions of the library.

        Verifying them with the following products/services, I suspect that a bug has been introduced in the latest version of the library.

        • XMLSec Online XML Digital Signature Verifer (http://www.aleksey.com/xmlsec/xmldsig-verifier.html)
        • 1.4.3: [...] RESULT: Signature is OK
        • 1.4.4: [...] func=xmlSecOpenSSLEvpSignatureVerify:file=signatures.c:line=346:obj=rsa-sha256:subj=EVP_VerifyFinal:error=18:data do not match:signature do not match
          RESULT: Signature is INVALID
        Show
        Giacomo Boccardo added a comment - - edited I attached two files (test14 {3|4} .xml) generated signing the same document using the two different versions of the library. Verifying them with the following products/services, I suspect that a bug has been introduced in the latest version of the library. XMLSec Online XML Digital Signature Verifer ( http://www.aleksey.com/xmlsec/xmldsig-verifier.html ) 1.4.3: [...] RESULT: Signature is OK 1.4.4: [...] func=xmlSecOpenSSLEvpSignatureVerify:file=signatures.c:line=346:obj=rsa-sha256:subj=EVP_VerifyFinal:error=18:data do not match:signature do not match RESULT: Signature is INVALID DiKe ( https://www.firma.infocert.it/installazione/installazione_DiKe.php ) 1.4.3: "Firma XML OK" (= XML Signature OK) 1.4.4: "Firma non verificata" (= Signature not verified) FileProtector ( http://www.actalis.it/ , non-free): 1.4.3: verified 1.4.4: not verified GlobalTrustFinder Online Verifier ( http://www.globaltrustfinder.com/XMLSignatureVerificationStep1.aspx ) should be used using a certificate which they trust...!
        Hide
        Colm O hEigeartaigh added a comment -

        Hi,

        I think I've found the problem. A regression was introduced in Canonicalizer11.java:

        425c425
        < if (XML_LANG_URI == N.getNamespaceURI()) {

        > if (!XML_LANG_URI.equals(N.getNamespaceURI())) {

        I've fixed this and attached a 1.4.5-SNAPSHOT version of the jar to this JIRA. Could you test the jar to see if it produces the same signature as per the 1.4.3 version?

        Thanks,

        Colm.

        Show
        Colm O hEigeartaigh added a comment - Hi, I think I've found the problem. A regression was introduced in Canonicalizer11.java: 425c425 < if (XML_LANG_URI == N.getNamespaceURI()) { — > if (!XML_LANG_URI.equals(N.getNamespaceURI())) { I've fixed this and attached a 1.4.5-SNAPSHOT version of the jar to this JIRA. Could you test the jar to see if it produces the same signature as per the 1.4.3 version? Thanks, Colm.
        Hide
        Giacomo Boccardo added a comment -

        Now the signatures are the same. I hope this version will be released as soon as possible

        Thanks,
        J.

        Show
        Giacomo Boccardo added a comment - Now the signatures are the same. I hope this version will be released as soon as possible Thanks, J.

          People

          • Assignee:
            Colm O hEigeartaigh
            Reporter:
            Giacomo Boccardo
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development