Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Blocker Blocker
    • Resolution: Unresolved
    • Affects Version/s: Java 1.4.5
    • Fix Version/s: None
    • Component/s: Java
    • Security Level: Public (Public issues, viewable by everyone)
    • Labels:
      None
    • Environment:
      Windows 7

      Description

      When generating Enveloping signatures in 1.4.5, they are invalid. These signatures worked in 1.4.4, but now do not work in 1.4.5

      1. Test.java
        4 kB
        William R. Speirs

        Activity

        Hide
        William R. Speirs added a comment -

        Sample code that when run with 1.4.4 is valid, invalid in 1.4.5

        Show
        William R. Speirs added a comment - Sample code that when run with 1.4.4 is valid, invalid in 1.4.5
        Hide
        sean.mullan added a comment -

        The test is generating the signature using the org.apache.xml.security APIs, and validating the signature using the JSR 105 APIs (javax.xml.crypto).

        It seems like a bug or interoperability issue between JDK 6 and Apache Santuario 1.4.5. I believe you are using JDK 6 right? If so, you are by default using the JSR 105 implementation from JDK 6 and not the one bundled with XMLSec 1.4.5. See my blog entry on how to use JDK 6 or later and override it with the JSR 105 implementation in Santuario: http://blogs.oracle.com/mullan/entry/using_more_recent_apache_xml

        When I tested with the JSR 105 implementation in Santuario 1.4.5 I did not see the problem.

        I'll need to investigate this issue a bit more first to see what the problem may be, and whether it is in JDK 6 or Santuario. Possibly/probably some sort of a C14N issue.

        Show
        sean.mullan added a comment - The test is generating the signature using the org.apache.xml.security APIs, and validating the signature using the JSR 105 APIs (javax.xml.crypto). It seems like a bug or interoperability issue between JDK 6 and Apache Santuario 1.4.5. I believe you are using JDK 6 right? If so, you are by default using the JSR 105 implementation from JDK 6 and not the one bundled with XMLSec 1.4.5. See my blog entry on how to use JDK 6 or later and override it with the JSR 105 implementation in Santuario: http://blogs.oracle.com/mullan/entry/using_more_recent_apache_xml When I tested with the JSR 105 implementation in Santuario 1.4.5 I did not see the problem. I'll need to investigate this issue a bit more first to see what the problem may be, and whether it is in JDK 6 or Santuario. Possibly/probably some sort of a C14N issue.
        Hide
        William R. Speirs added a comment -

        I think it's an issue with Santuario 1.4.5. In our particular use case we're generating signatures with Java and verifying them with C+. This is initially how we found the issue; however, I wrote a test case in Java as a simple example. We are unable to verify signatures generated by 1.4.5 in Java with C+.

        Show
        William R. Speirs added a comment - I think it's an issue with Santuario 1.4.5. In our particular use case we're generating signatures with Java and verifying them with C+ . This is initially how we found the issue; however, I wrote a test case in Java as a simple example. We are unable to verify signatures generated by 1.4.5 in Java with C +.
        Hide
        Scott Cantor added a comment -

        Your test sample seems to be problematic to begin with, you can't use xml as a namespace prefix unless it's defined to be what XML requires (it's reserved). I'm surprised it's parseable, but the bug may simply be a lack of proper error checking for that situation in one of the libraries.

        In any case, I'd start by using something other than "xml" and see what happens.

        Show
        Scott Cantor added a comment - Your test sample seems to be problematic to begin with, you can't use xml as a namespace prefix unless it's defined to be what XML requires (it's reserved). I'm surprised it's parseable, but the bug may simply be a lack of proper error checking for that situation in one of the libraries. In any case, I'd start by using something other than "xml" and see what happens.
        Hide
        William R. Speirs added a comment -

        I'll be the first to admit I'm a novice at best when it comes to XML and understanding namespaces, baseURIs and all other fun stuff it has. However, it seems as though that is the issue. Changing the XML in my test code to String xml = "<test><foo>bar</foo></test>"; results in valid signatures for both 1.4.4 and 1.4.5.

        So I agree/think that it should probably not generate a signature for the XML if I've screwed it up and/or throw some kind of exception during signing or verification.

        Thanks for the help though!

        Show
        William R. Speirs added a comment - I'll be the first to admit I'm a novice at best when it comes to XML and understanding namespaces, baseURIs and all other fun stuff it has. However, it seems as though that is the issue. Changing the XML in my test code to String xml = "<test><foo>bar</foo></test>"; results in valid signatures for both 1.4.4 and 1.4.5. So I agree/think that it should probably not generate a signature for the XML if I've screwed it up and/or throw some kind of exception during signing or verification. Thanks for the help though!
        Hide
        Scott Cantor added a comment -

        It's hard to say exactly what it should do, but I would suggest keeping this open for investigation into what layer is behaving oddly. I'm not really surprised the parsers are broken enough to accept this, and having done that, it's not likely we could or should be just refusing to sign it. The checking alone would add inefficiencies that other people shouldn't pay for.

        As far as the bug, c14n handles the XML namespace (the one hardwired to that prefix) very particularly, and there's no such thing as an element in that namespace. So I'm sure there's just some code getting confused, and probably behaving differently in different implementations. But it would be good to know where.

        It also may mean there's a regression somewhere involving c14n of the xml namespace declaration itself, which was an older bug.

        Show
        Scott Cantor added a comment - It's hard to say exactly what it should do, but I would suggest keeping this open for investigation into what layer is behaving oddly. I'm not really surprised the parsers are broken enough to accept this, and having done that, it's not likely we could or should be just refusing to sign it. The checking alone would add inefficiencies that other people shouldn't pay for. As far as the bug, c14n handles the XML namespace (the one hardwired to that prefix) very particularly, and there's no such thing as an element in that namespace. So I'm sure there's just some code getting confused, and probably behaving differently in different implementations. But it would be good to know where. It also may mean there's a regression somewhere involving c14n of the xml namespace declaration itself, which was an older bug.

          People

          • Assignee:
            sean.mullan
            Reporter:
            William R. Speirs
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development