In the [DOM], [XPath] and consequently [XML-C14N] data models, an element has namespace nodes that correspond to those declarations within the element and its ancestors:
"Note: An element E has namespace nodes that represent its namespace declarations as well as any namespace declarations made by its ancestors that have not been overridden in E's declarations, the default namespace if it is non-empty, and the declaration of the prefix
xml." [XML-C14N]
When serializing a Signature element that's the
child of other elements using these data models, that
Signature element, and/or its children, may contain
namespace declarations from its ancestor context. This may
frustrate the intent of the signer to create a signature in one
context which remains valid in another. For example, given a
signature which is a child of B, which is a child of
A:
<A xmlns:n1="&foo;">
<B xmlns:n2="&bar;">
<Signature xmlns="&dsig;">
...
</Signature>
<n2:Foo bar="value">
... some XML signed by Signature Above ...
</n2:Foo>
</B>
</A>
when the signature element B, or signed XML such as n2:Foo,
is moved into a different context, such as a
[SOAP] envelope for transport:
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
...
<SOAP:Body>
<B xmlns:n2="&bar;">
<Signature xmlns="&dsig;">
...
</Signature>
<n2:Foo bar="value">
... some XML signed by Signature Above ...
>/n2:Foo>
</B>
</SOAP:Body>
</SOAP:Envelope>
The canonical forms of the Signature and
n2:Foo XML data elements in this new context will
contain new namespace declarations from the
SOAP:Envelope context, invalidating the signature.
Also, the canonical forms will lack namespace declarations it may
have originally had from element A's context
(n1 above), also invalidating the signature. The same
problem arises with all attributes in the xml namesapce, such as
xml:lang, xml:space, which canonical XML
requires to be copied from their nearest ancestor occurance into the
apex node of the canonicalized document subset if not already
present there.
Applications that wish to create signatures that survive porting MUST take the following or equivalent steps:
Rely upon the signature applications to properly divorce the
Signature and/or any signed XML data (including
Manifest, SignatureProperties, and
Object elements) from their context before both
generating and validating the signature. While this is simple, it is
not, in general, interoperable. If a signature generating
application so divorces signature or XML data because it might need
to be verified in a different context but a verification application
does not so divorce the signature or XML data, the signature can be
broken, even when verification is attempted in the same context as
generation! This is because enveloping namespaces would not have
been allowed to invade the signed/digested material on generation
but would, changing it, on verification. The same is true, breaking
interoperability, if signature generation does not divorce from
context but verification does. Thus this technique gnerally requires
absolute coordination outside of XMLDSIG between all signature
generators and verifiers involved.
For signed XML data (but not necessarily for
SignedInfo which is discussed in the next point below),
use XPath or other Transform opertions such as a
canonicalization method to repel the invasion of the XML by ancestor
namespace declaration and xml namespace attribute context. This
method has the virtue that it is documented within the
Signature strucuture by the signature generator and
thus will be interoperable with conformant verifiers. It has the
disadvantage that implementation is not required of XPath, such a
context repelling canonicalization, or other Transform
operation that can accomplish this. [XML-C14N] purposefully incorporates
namespace declaration and xml namespace attribute context; an
alternative which does not and isolates the canonicalized XML from
its context is specified in [W3C additional XMLDSIG URIs Note].
The SignedInfo element presents a special problem
which distinguishes it from general XML data. Due to the sensitivity
of SignedInfo, Transform operations over
it are not provided, only CanonicalizationMethod, and great
care must be taken to only use safe caonicalizations of
SignedInfo. Thus, the only interoperabile solution for
portability of the Signature element iself, and thus
the SignedInfo element therein, is the implementation
and use of a canonicalization that repels ancestor namespace
declaration and xml namespace attribute context.