摘要

  • XML 解析器输出的是信息集，不是接收字节的原样收据；编码、实体、空白和规范化会影响签名究竟覆盖了什么。
  • 有效签名只证明其明确引用和转换后的数据，不能自动证明应用使用的全部节点、业务授权、状态提交或用户结果。

两份报文都能通过解析。应用展示出来的树几乎一样。签名校验端却只接受其中一份。

差异可能来自编码、换行、属性表示、命名空间声明位置，也可能来自规范化器选取的节点集合。解析器为了给应用提供 XML Information Set，会抽象掉一部分具体语法。密码学系统若在另一阶段处理另一组输入，“看起来一样”便不再是可用的证据。

RFC 3470 于 2003 年 1 月以最佳当前实践 70 发布。它没有声称 XML 是所有 IETF 协议的首选格式，而是回答已经选用 XML 后，哪些责任不能交给“解析成功”四个字。

先保存字节，再讨论树

格式良好是第一道门。起止标签、字符和结构符合 XML 规则，处理器才可生成信息集。对于格式不良的文档，RFC 3470 要求不得选取可读片段继续解释；协议可以重传或中止，但不应让双方在不同残片上推进状态。

通过这道门也不等于保存了原始事实。字符编码会把八位字节变成字符；行尾可能被规范化；属性次序不具 XML 语义；实体可以展开；默认值可能由验证器补入。最终树是解释结果，不是线路镜像。

因此第一张收据应包含接收字节的散列、传输封装、媒体类型、时间与编码依据。第二张才是解析器名称、版本、配置、外部访问策略与严格格式良好结果。若日志只留下序列化后的树，争议发生时很难恢复签名端真正见过的输入。

XML 声明应当被接受。当协议允许 UTF-8、UTF-16 以外的编码时，声明更是必要坐标。UTF-16 的字节序要求同样不能在重放时猜测。

规范化是一项转换，不是事实抹平器

RFC 3076 定义 Canonical XML，用共同规则为节点集合生成可重复的序列化。它解决部分合法语法差异，却不会回答节点集合选得对不对。

一张规范化收据至少要说明算法、参数、输入节点、命名空间上下文以及转换前后的散列。只记录最终摘要，会把“选择了哪些数据”和“如何表示这些数据”混成一个结果。

自创 XML 子集并不能取代共同规范化。某实现若只接受自家生成器输出的属性次序或引号风格，另一实现完全可能产生合法 XML 却被拒绝。RFC 3470 反对这类临时语法限制，因为它把实现便利变成互操作障碍。

规范化也不等于语义相同。两个节点集合可产生稳定字节，却分别代表不同资源、不同版本或不同授权上下文。

签名只为引用范围说话

RFC 3275 的 XML Signature 使用引用和转换来界定被校验对象。验证成功的含义受这套范围约束。签名覆盖某个子树，并不自动覆盖应用稍后读取的兄弟节点、外部模式补入的默认值或另一 URI 解析得到的内容。

完整记录要保留引用目标、解析后的节点集合、全部转换、规范化算法、密钥与认证身份。随后还要证明应用实际消费的数据是否落在该范围中。

身份、完整性和授权是三件事。某身份可以真实签署一条命令，却没有权力在当前状态执行它。密码学通过之后，仍需业务规则、权限检查、前置状态、提交结果与回滚记录。

最后的绿色结果必须来自认证的下游或用户可见结果，不能从“签名有效”推断出来。

命名空间给词汇命名，不给机构颁权

XML 命名空间用 URI 形态的名称区分词汇。这个 URI 首先是标识符，并不必然需要访问；其中出现某组织域名，也不是发送者代表该组织行动的凭证。

默认命名空间只适用于无前缀元素，不适用于无前缀属性。若应用按视觉嵌套把两者归为同一权威来源，合法文档也能被错误解释。

扩展行为更需要协议明说：未知扩展是忽略、保存、转发、拒绝，还是因“必须理解”而失败。XML 语法不替协议治理这些选择。处理指令和注释也不应暗藏规范性扩展，因为正常处理路径应能够忽略它们。

每次分派应记录展开后的名称与所选处理器，而不是只保存前缀。前缀可以更换，词汇身份由展开名称决定。

模式验证不会证明业务真实

DTD、XML Schema 等形式化工具能表达不同的结构约束。RFC 3470 明确指出，不可能把所有协议条件都压进一种模式语言；语义规则必然留在规范文字和应用代码中。

验证结果必须带上模式或配置文件身份、版本、来源以及是否插入默认值。一个验证器可能在树中添加报文从未携带的默认属性，而抓包工具看不到它。两份记录差异来自处理环境，不等于谁伪造了报文。

字段符合类型，不代表值为真、未过期、与外部状态一致或获得授权。模式是结构收据，不是现实世界的证词。

应用若依赖外部模式，还需把其精确字节纳入证据。今天重新下载相同 URI，不是对昨天决定的可靠重放。

外部引用把解析器变成网络主体

外部实体、远程模式和相对 URI 可让报文含义依赖线路之外的对象。更敏感的是，解析器会从自己的网络位置发起请求。外部发送者可能借此触达其无法直接访问的内部地址，泄露解析环境或消耗资源。

RFC 3470 建议协议避免实体声明，并要求处理不可信 XML 时禁止任意外部访问。五个预定义实体与数字字符引用无需远程获取，应保留为普通语法能力。

xml:base 还会与传输层或容器提供的基 URI 发生优先级问题。协议若未规定，两个实现可能把同一相对引用解析到不同对象。

证据应说明外部访问完全关闭、使用固定本地目录，还是严格白名单；并记录每个实际解析 URI 与取得内容。否则无法区分输入改变和环境改变。

空白并非总是排版

XML 默认把字符信息交给应用。人眼认为用于美化的缩进与换行，在协议未另行规定时可能就是字段内容。一次“格式化”足以改变待签名值或业务含义。

相反，属性次序没有 XML 语义，属性值也可能规范化。若系统把源次序作为含义或签名依据，它就在标准之外创造了隐藏协议。

协议必须明确空白、混合内容、元素次序、属性使用与扩展保留。屏幕显示相似不是等价证明。

安全还要约束实现成本

XML 自身不提供保密性、完整性、认证或授权。解析器代码面对攻击者可控的嵌套、扩展和引用，可能遭遇资源耗尽、缓冲区问题或实体滥用。

安全收据需要大小、深度、展开、时间、内存与网络访问上限，也要记录失败时是否完整回滚。合乎语法的文档仍可能要求不可接受的工作量。

RFC 8996 后来更新了 RFC 3470 的 TLS 背景，弃用 TLS 1.0 与 1.1。现代传输保护仍只覆盖相应通道，不能证明签名范围完整或应用授权正确。

从八位字节到结果的十四张收据

依次保存接收字节与编码、解析器与配置、格式良好结果、完整失败行为、实体与基 URI、外部资源、信息集、模式版本与验证、命名空间与扩展分派、规范化、签名引用、认证身份、应用语义与授权、提交状态和最终结果。

声称互操作时，再用关闭外部访问的环境和另一合规实现进行重放。两个实现都报告“XML 有效”却产生不同节点或决定，本身就是缺失规范的证据。

证据边界

本文不指控任何产品、解析器或现场事件，也不主张模式、规范化和签名无用。它限定每项控制能够证明的范围。

本文不重复 BTW 已有的 YANG/XML 文章；后者负责有效 YANG 树、默认值、模式修订、挂载上下文、数据存储与网络效果。这里讨论所有 XML 协议共有的字节到应用决策链。

Heng Lu 的“最小初始规范”和“运行代码优先”是明示的编辑分析镜头：共同规范只覆盖必须互操作和安全的边界，事实以运行路径收据约束。它们不是部署测量。

结论很窄：签名只有在输入、引用、转换和应用消费范围一致时才有可审计意义。解析成功不能代签这张收据。

Sources