命名空间前缀更改时，如何验证XML签名？

Question

所有，

我正在测试一些验证XML数字签名的Java代码。 我在JDK中使用标准的JSR 105 API。 我正在使用排他性规范化方法和信封签名。 传入的XML消息如下所示：

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

该消息通过具有各种XML解析器（CXF，JAXB，XSLT等）的复杂系统，并且以某种方式更改为：

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

更改后，附加的XML签名将不再有效。 参考无效。

我认为，即使此XML文档发生了变化，它似乎也是等效的XML。 唯一更改的是名称空间前缀。 我不确定名称空间前缀更改是否符合XML规范化规则。 我的问题是：

1. 应该行吗？
2. 我如何才能使其正常工作（转换等）？

任何帮助表示赞赏，

g8torPaul

Answer 1

希望我对你有个好消息...

不幸的是，用于XML签名的标准算法（ http://www.w3.org/TR/xmldsig-core/#sec-AlgID ）在规范化表示（ http://www.w3.org/TR/2001/ XML文档的REC-xml-c14n-20010315 ）， 而不是其语义。 命名空间前缀被认为是文档签名内容的一部分。

（对此，存在一些争论，例如可能在字符串中使用命名空间前缀，并从上下文中隐式绑定它们，例如在XSLT中发生的那样。这实际上是一种不好的做法，但是XML Recommendations建立了它，并且已经很普遍了……完成此操作后，如果不知道特定类型文档的完整语义，就不可能可靠地规范化。）

因此，尽管最初的意图是前缀仅是名称空间URI的“语法糖”，但实际上不谨慎地更改前缀确实有可能破坏某些工具，尤其是更改它们总是会更改XML签名。

这种情况是XML以渐进的和不自然的顺序快速发展的产物。 事后考虑保留XML命名空间，XML Schema和XML Infoset确实可以更快地将XML发布给用户并帮助其获得接受...但是也使得将这些更复杂的语义改型为现有XML语法变得更加困难，并且导致一定程度的阻抗失配并导致疼痛，因为事情无法顺利进行。 有一天，可能会有一个XML 2.0，它从信息集开始，并从中获取语法和工具，但是直到那一天，我们仍将停留在少数情况下，其中明显需要做的事情要么是不必要的工作，要么根本没有可能。