How can I validate an XML Signature when a namespace prefix changes?

Question

All,

I am testing some java code that validates an XML digital signature. I am using the standard JSR 105 API in the JDK. I am using an Exclusive Canonicalization method and an Enveloped signature. The incoming XML message looks something like this:

<doc xmlns:a="urn:abc.my.domain.com">
    <a:x>12345</a:x>
</doc>

This message goes through a complex system with various XML parsers (CXF, JAXB, XSLT, etc.) and somehow gets changed to this:

<doc xmlns:b="urn:abc.my.domain.com">
    <b:x>12345</b:x>
</doc>

After the change, the XML signature that is attached will no longer validate. The Reference is not valid.

In my opinion, even though this XML document changed, it appears to be equivalent XML. The only thing that changed was the namespace prefix. I am not sure if namespace prefix changes meet the rules for XML Canonicalization. My questions are:

1. Should this work?
2. How can I get this to work (Transformation, etc.)?

Any help is appreciated,

g8torPaul

Answer 1

I wish I had better news for you...

Unfortunately, the standard algorithms for XML Signatures (http://www.w3.org/TR/xmldsig-core/#sec-AlgID) operate on the canonicalized representation (http://www.w3.org/TR/2001/REC-xml-c14n-20010315) of the XML document, not its semantics. Namespace prefixes are, alas, considered part of the signed content of the document.

(There are arguments for this involving the possible use of namespace prefixes inside strings with implicit binding from their context, as occurs in XSLT for example. That's actually a bad practice, but the XML Recommendations established it and it has become common... and when this is done, it is impossible to canonicalize reliably without knowing the complete semantics of the particular type of document.)

So, despite the original intent that prefixes be nothing but "syntactic sugar" for namespace URIs, in practice changing them incautiously does risk breaking some tools, and in particular changing them will always change the XML Signature.

This situation is an artifact of the rapid development of XML in incremental and somewhat unnatural order. Leaving XML Namespaces, the XML Schema, and the XML Infoset as afterthoughts did permit getting XML out to the users much more quickly and helped it gain acceptance... but also made retrofitting these more sophisticated semantics to the existing XML syntax more difficult, and has resulted in a certain amount of impedance mismatch and resulting pain as things don't fit as smoothly as they should. Someday there may be an XML 2.0 which starts with the infoset and derives the syntax and tooling from that, but until that day we're going to be stuck with a few cases where something obviously desirable is either much more work than necessary or simply not possible.