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

【问题标题】：How can I validate an XML Signature when a namespace prefix changes?命名空间前缀更改时如何验证 XML 签名？
【发布时间】：2013-12-03 14:07:53
【问题描述】：

全部，

我正在测试一些验证 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 规范化的规则。我的问题是：

这应该有效吗？
我怎样才能让它工作（转换等）？

感谢您的帮助，

g8tor保罗

【问题讨论】：

标签： java xml namespaces signature canonical-link

【解决方案1】：

我希望我有更好的消息告诉你...

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

（有一些争论涉及可能在字符串中使用名称空间前缀，并从其上下文中隐式绑定，例如在 XSLT 中发生的情况。这实际上是一种不好的做法，但 XML 建议建立了它并且它已经变得普遍。 .. 完成此操作后，如果不知道特定类型文档的完整语义，就不可能可靠地规范化。）

因此，尽管最初的意图是前缀只是命名空间 URI 的“语法糖”，但实际上不小心更改它们确实有破坏某些工具的风险，尤其是更改它们总是会更改 XML 签名。

这种情况是 XML 以增量且有点不自然的顺序快速发展的产物。将 XML 命名空间、XML 模式和 XML 信息集作为事后的想法确实可以更快地将 XML 提供给用户并帮助它获得接受……但也使得将这些更复杂的语义改进为现有的 XML 语法变得更加困难，并且已经导致一定程度的阻抗失配并导致疼痛，因为事情没有像他们应该的那样顺利。总有一天，可能会有一个 XML 2.0，它以信息集开头并从中派生语法和工具，但直到那一天，我们将被困在一些情况下，显然需要的东西要么比必要的工作多得多，要么根本不需要可能。

【讨论】：

感谢您的反馈 keshlam。在阅读了一些提议的 XML 2.0 规范后，我得出了相同的结论。似乎有计划扩展 Canonical XML 规范以包括命名空间重写，但目前不支持。
你知道，我很想引入“LMX”，它将以正确的顺序重新派生 XML...语义不会相同，因为它们会消除冲突...但是因为这明确不会是可以确定的 XML。