摘要

  • RFC 5402 允许先压缩内层 MIME 再签名，也允许先签名再压缩整个 multipart/signed；两种顺序都合法，却覆盖不同的字节边界。
  • 签名消息的返回 MIC 必须针对当初实际签名的数据；非签名压缩消息则按规范在解压后的 MIME 边界计算。
  • 已签名回执能够证明特定伙伴对接收和完整性状态的声明，但不能替代解压、附件校验、交易入账或商业接受凭据。

“已处理”不是一个自然事实

控制台只有一个状态栏，于是不同团队把自己的完成条件都塞进同一个词。传输团队认为 HTTP 成功就是已处理；密码团队认为签名和 MIC 通过才算；集成团队要看到附件被解析；财务团队则要等订单进入账务流程。

这四种定义并不必然冲突，却不能共用一个没有层级坐标的布尔值。发生争议时，任何人都可以指向绿色界面，却没人能回答它验证了哪一组字节、采用哪条规范路径、在哪一步结束。

RFC 5402 于 2010 年 2 月以 Independent Stream 的 Informational 文档发布，并带有 IESG 提醒：它不是 Internet Standards Track 规范，评估实现与部署价值时应保持谨慎。该文档为 AS1、AS2 和 AS3 的 EDIINT 消息加入 CMS 压缩层。它提供的是可互操作的处理规则，不是某个供应商或伙伴已经正确部署的证明。

层序决定 MIC 的含义

EDIINT 消息原本就可能包含业务载荷、签名和加密。压缩加入后，发送方可以先压缩最内层 MIME，再对压缩实体签名；也可以先生成 multipart/signed，再压缩整个已签名结构。RFC 5402 禁止在同一文档里同时使用这两种位置，并要求接收方支持两种解包方式。

第一种情况下，签名覆盖 CMS CompressedData。第二种情况下，签名覆盖未压缩的业务 MIME，随后签名和内容一起被外层压缩。RFC 5402 对签名消息的 MIC 规则是：返回值必须针对原消息中被签名的同一份数据。

因此，“文档 MIC”不是充分字段。它至少需要层序、签名覆盖范围、规范化规则、哈希算法和阶段名称。两个不同的摘要可能分别对应压缩前和压缩后的合法边界；一个与最终 XML 相同的摘要，也未必复现了对方回执中的输入。

如果供应商只导出最终文件和 processed=true，迁移后便无法独立重放旧交易。数据可携带性不只是下载业务文档，还要能重建证据路径。

MIME 头和 base64 不是包装纸

RFC 5402 说明，二进制压缩体若暴露在 SMTP 等七位传输上，需要使用 base64 Content-Transfer-Encoding。若压缩体位于加密层内部，内层不必单独 base64，编码应落在外部加密体上。

这决定了线上实际出现的是哪种表示。源 MIME、压缩后的 CMS、加密信封以及 base64 文本都可能有各自的哈希。接收端再依次完成传输解码、解密、解压和 MIME 解析。只保留最终 XML，会让换行转换、截断、解密错误和解压错误都失去定位依据。

在未签名的压缩场景中，RFC 5402 要求 MIC 基于解压后的内容，并包含 MIME 头以及适用的 Content-Transfer-Encoding。RFC 4130 还规定了 AS2 的规范化。操作人员把 XML 美化后重新哈希，得到的只是一个新文件摘要，不一定是协议证据。

所以每个阶段都应有明确名称：source-mime、compressed-cms、encrypted-envelope、wire-transfer、decrypted、decompressed、extracted-attachment。名称必须跟随哈希，否则哈希值只是无法解释的字符串。

支持 ZLIB 不代表完成协商

RFC 5402 要求实现支持 ZLIB，而 ZLIB 使用 DEFLATE。RFC 3274 定义 CMS CompressedData 和算法标识，并说明压缩级别不必放进参数，因为不同级别仍可由同一解压算法处理。

然而 RFC 3274 同时记录了一个历史兼容细节：算法参数字段可能被省略，也可能编码为 ASN.1 NULL。规范更倾向于省略，但实现可能遇到两种形式。一个只接受其中一种的产品，仍然可以在营销资料里写“支持 ZLIB”。

层的位置、MIME 规范化、大小限制、错误处理和双边协议也不由 ZLIB 能力自动确定。RFC 5402 要求使用其压缩方式时，AS2 或 AS3 版本头至少为 1.1。版本头说明意图和能力范围，却不能证明某一条消息已按预期路径完成。

可靠记录要分开能力宣告、伙伴授权、当前配置和本次观察结果。否则某次升级关闭压缩后，旧能力声明仍会让监控误报成功。

失败回执不应被压成“拒绝”

当请求了回执而解压失败时，RFC 5402 规定已签名 MDN 返回 Error: decompression-failed。这是一份有价值的负面凭据：在验证签名后，可以确认接收伙伴报告自己无法跨过压缩层。

但它没有说订单内容经业务审查后被拒绝。接收方可能根本没有恢复出订单。它也没有单独证明发送端源文件错误；问题可能发生在编码、传输、大小限制或算法解释上。

RFC 4130 更明确：即使内容处理失败，请求的签名回执仍必须返回，而交易本身可能无效。回执签名认证的是报告和报告者，不会把失败变成成功，也不会替业务系统作决定。

因此，decompression-failed 应进入可重放的技术异常队列，关联线上字节、层序和伙伴配置。把它映射成统一“伙伴拒绝”，会触发错误的业务补偿，也会丢掉真正的修复入口。

多附件交换有共同完整性，也有各自命运

RFC 6362 允许在 multipart/related 内发送多个附件。对压缩但未签名的消息，MIC 覆盖经过传输规范化的整个解压 multipart 内容。若预期 MIC 与计算值不一致，所有附件都被视为无效并要求重传。

这是共同的完整性边界，不是共同的业务结论。通过后，订单 XML、说明 PDF 和图片仍要分别提取、校验类型、检查语法并交给不同应用。RFC 6362 明确把文档存储和交易处理留给具体实现。

数据模型应保留父级交换记录和子级附件记录。父级保存共同的 MIME、签名、MIC 与回执；子级保存 Content-ID、媒体类型、提取哈希、验证结果和应用决定。否则一个附件失败可能被误写为整个传输受损，而共同 MIC 也可能被错误复制成每个附件的内容批准。

完整凭据链从伙伴协议开始

发送前记录伙伴协议、版本要求和允许的压缩位置。构建时保存源 MIME、规范化规则、算法标识与参数形式、被签名字节和被加密字节。接收时保存传输解码、解密、解压、签名验证和 MIC 计算配方。

MDN 还应保留其签名验证、伙伴证书上下文、原始消息标识与 disposition。此后才进入附件提取、格式验证、去重、交易关联、权限判断与商业接受。

这些权威来源没有提供当前厂商覆盖率、实际部署比例或某次事故证据。它们足以否定一个常见捷径：一个绿色“已处理”不能同时承担传输、密码、解析和业务四种含义。