摘要

  • RFC 3075 的 SignatureValue 覆盖规范化后的 SignedInfo；其中的 Reference 通过摘要承诺的是资源经过有序 Transforms 后的结果，不是读者直觉中的“整份文档”。
  • 核心验证通过以后，未被选中的节点、外部样式、未绑定的 KeyInfo、Manifest 内部成员以及应用授权仍可能没有相应回执。

2001 年 3 月，XMLDSIG 工作组发布 RFC 3075。它允许同一种签名结构处理 XML 与非 XML 数据：对象可以被签名包住，可以包住签名，也可以远在另一个 URI。这样的通用性让 Web 数据获得了可组合的签名机制，也把“签名有效”拆成了一组必须逐项核对的事实。

核心验证其实有两张收据

第一张是引用验证。验证器为 SignedInfo 中的每个 Reference 取得数据对象，执行或取得变换后的输入，使用指定算法计算摘要，再与 DigestValue 比较。第二张是签名验证：按照 CanonicalizationMethod 规范化 SignedInfo，再用选定密钥和 SignatureMethod 检查 SignatureValue。

只验证第二张不够，因为真实签名也可能包着错误的引用摘要；只验证第一张也不够，因为匹配的摘要还没有被签名者认证。两者都通过时，能够证明的是某个密钥认证了一组具体摘要、算法和处理标识。它不会自动把保护范围扩大到签名元素附近的全部节点，更不会替应用回答“应不应该信任这项业务动作”。

变换链决定“被签的对象”

Reference 可以携带有序变换。XPath 可以只选择树中的部分节点；XSLT 可以生成另一种表示；Base64 变换可以把可见字符还原成二进制；规范化可以把节点集重新序列化为稳定字节。摘要针对的是链尾结果。

这并非必然缺陷。表单可以保护固定条款，同时允许用户填写预留字段；封装式签名必须把自己的签名值排除在计算之外；XML 容器也可以承载真正要签的原始二进制。问题出现在界面或业务规则把“选定部分通过验证”说成“源树全部受保护”时。被 XPath 排除的金额、指令或目的地可以变化，而签名仍然正确地验证它原本被要求验证的对象。

RFC 3075 还留下了一个重要操作边界：核心验证未必证明验证器刚刚重新取得 URI 并逐步执行了所有变换。某个应用可以接受已经变换好的缓存副本，只要其摘要匹配；另一个应用可以坚持即时取回和执行。两者的密码学比较或许相同，证据新鲜度却不同。

规范化解决字节一致，不解决意义一致

XML 解析会统一换行、处理属性、展开实体、映射命名空间，还可能丢失属性顺序等源文件表面信息。DOM 与 SAX 看到的是树或事件，不是原始字节。若签名者和验证者无法重新得到同一串输入，密码学计算就没有可比性。

规范化为此提供稳定序列化。它证明双方可以对同一信息模型计算相同字节，却不证明两种显示效果相同、某份 schema 可信、命名空间含义符合应用假设，或被删去的节点无关紧要。后来 Canonical XML 1.1 同样把通用规范化与应用特定等价规则区分开来。

所见内容必须与被签内容相接

RFC 3075 的安全章节直接处理“所见即所签”。如果签名要表达个人或自动系统的判断，就应尽可能保护当时呈现的材料。可以直接签屏幕图像，但那会牺牲结构化处理；另一条路是把数据以及影响呈现的过滤器、样式表、客户端配置一并纳入保护。

依赖方也有对称义务：它应操作和展示变换后的已签形式，而不是悄悄换回源数据或中间状态。若外部样式表影响读者看到的结果，却没有成为签名引用，样式变化可以改变呈现而不使数据签名失效。

这不等于 RFC 3075 承诺了“电子同意”。它明确只把密钥与被引用的字节联系起来，并不规范密钥如何对应个人或机构，也不替应用解释数据的社会或法律含义。

KeyInfo 找到密钥，不自动建立信任

KeyInfo 可以放公钥、证书资料、名称或远程取回方法，也可以完全省略，由应用上下文提供密钥。它默认位于 SignedInfo 之外。若签名者希望绑定这部分资料，可以另设 Reference 把它纳入摘要。

即使字节被绑定，信任判断仍未结束。证书可能完整却不适用于当前权限；KeyName 可能准确却只在某个局部系统有意义。RFC 2807 早已限定工作范围：XML Signature 提供内容与密钥之间的密码学联系，任意信任语义和断言语义由应用补足。

Manifest 的外框通过，不代表每个成员都通过

Manifest 提供一组引用，允许应用对资源不可达或摘要失败采用更灵活的政策。当 SignedInfo 引用某个 Manifest 时，核心验证会检查 Manifest 元素本身的摘要；至于内部哪些引用实际接受验证、失败时怎样处理，由应用决定。

所以“Manifest 已签名”和“清单内每个对象都已取得、变换并匹配”是两句话。前者不能代替成员级结果。操作记录若只留下外层绿色状态，就会把应用尚未执行的工作伪装成密码学结论。

后来的规范收紧了执行边界

RFC 3275 在 2002 年 3 月取代 RFC 3075，并根据互操作经验调整若干结构。W3C XML Signature 1.1 与后来的最佳实践继续保留原有分界，同时建议：先认证 SignedInfo，再执行可能危险的引用操作；独立建立验证密钥的信任；限制 XPath、XSLT、RetrievalMethod、变换数量与外部 URI；由应用明确确认真正需要使用的元素确实受保护。

这些后续材料不能证明某个 RFC 3075 实现遭遇过攻击。它们说明的是结构性事实：签名描述本身具有选择与执行能力，因此密码学库的成功返回必须被更窄的应用策略包围。

Lu Heng 的 Running-Code Primacy 与 Reality Layers 是后来的分析工具，不属于 RFC 3075。前者提醒我们保存真正进入算法的输入和运行结果，后者帮助分开“已签”的符号声明、被选中字节、用户显示、信任决定与实际后果。RFC 自己已经给出了底线：只有真正进入签名范围的内容才得到那份保护。

来源

Lu Heng 没有撰写或批准 RFC 3075、RFC 3275 或 W3C 建议；两篇文章仅作为明确披露的后续分析框架。