Question

全部，

我正在测试一些验证XML数字签名的java代码。我在JDK中使用标准的JSR 105 API。我正在使用Exclusive Canonicalization方法和Enveloped签名。传入的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规范化的规则。我的问题是：

这应该有用吗？
我怎样才能让它发挥作用（转型等）？

感谢任何帮助，

g8torPaul

Answer 1

我希望我有更好的消息......

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

（有一些参数涉及可能在字符串中使用名称空间前缀与来自其上下文的隐式绑定，例如在XSLT中发生。这实际上是一种不好的做法，但XML Recommendations建立了它并且它已经变得很普遍。 ..当这样做时，如果不知道特定类型文档的完整语义，就不可能可靠地规范化。）

所以，尽管最初的意图是前缀只是命名空间URI的“语法糖”，但实际上不谨慎地改变它们会冒一些工具的风险，特别是更改它们总是会改变XML签名。

这种情况是XML以递增和有些不自然的顺序快速发展的工件。将XML命名空间，XML模式和XML信息集作为后续工作，确实允许更快地将XML发送给用户并帮助它获得认可......但是也将这些更复杂的语义更新为现有的XML语法更加困难，并且导致一定程度的阻抗不匹配并导致疼痛，因为事情并不像他们应该的那样顺利。有一天可能会有一个XML 2.0，它从信息集开始，并从中获得语法和工具，但直到那一天，我们仍然会遇到一些情况，其中明显需要的东西要么比必要的工作多得多，要么根本就没有可能的。

如何在命名空间前缀发生变化时验证XML签名？

1 个答案: