Summary

  • AS2-From 与 AS2-To 是交易伙伴约定、区分大小写的文本名称，不是由证书自动产生的全球身份。
  • draft-ietf-ediint-rfc4130bis-04 要求 TLS 证书与用于消息签名、加密的 AS2 证书分离；证书获取也必须经过认证和授权，自签名证书上线前还要核对带外指纹。
  • 有效签名、正确反射的名称、匹配的 Message-ID 与 MIC 只能证明各自层次。把特定名称、证书、方向和交易关系连接起来的权力，仍在本地伙伴配置中。

回执换了连接，权威没有随之生成

AS2 的同步 MDN 沿原 HTTP 连接返回，异步 MDN 则另建连接。后一种情况下，新连接上的 TLS 身份可以证明新端点，却不能倒推原始业务消息中的签名者是谁，也不能自行确定其商业授权范围。

第 04 版草案文本把这种分层写得比一个“安全连接”标签更清楚。Datatracker 页面显示它是 EDIINT 工作组的活动文档，文档 API状态为 I-D Exists，历史页记录第 04 版于 2026 年 9 月 24 日上传。目标状态是 Proposed Standard；它还不是 RFC，也只有在获得批准后才会取代 RFC 4130。

名称是双边约定，不是证书字段

第 6.3 节允许使用 DUNS 等公司标识，也允许伙伴自行约定字符串。名称由 1 至 128 个可打印 ASCII 字符组成，区分大小写，且必须出现在所有 AS2 消息和 MDN 中。响应里的 AS2-To 要匹配请求的 AS2-From，反向同理。

这套反射规则能支持路由与关联，却不会把字符串变成 DNS 名称、法人名称或证书主体。系统面对未知值时可以返回未签名 MDN，并使用 unknown-trading-relationship 或 unknown-trading-partner。判断“未知”的依据本身就是本地伙伴表；草案没有建立一个为每个 AS2 名称分配唯一公钥的全球登记处。

通道证书和消息证书属于两套安全域

HTTPS 的 TLS 证书保护传输端点。RFC 8446规定 TLS 1.3，RFC 9110规定 HTTP 语义；RFC 9525可作为现代服务身份的背景，但不能被说成 AS2 草案已经吸收的绑定规则。

AS2 证书保护消息和 MDN。S/MIME 与 CMS 的现行材料包括 RFC 8551 和 RFC 5652，证书路径背景可由 RFC 5280说明。草案明确要求 AS2 证书不得与 TLS 证书相同，从而让通道与消息的泄露、轮换和生命周期彼此隔离。

这种隔离也揭示了一个控制事实：TLS 健康不等于消息签名者已经获得伙伴授权；证书链有效也不等于它被放进了正确的伙伴行。证书颁发者判断一套信任政策，本地管理员决定它在某条双边关系里的含义。

获取公钥只是开始

草案建议支持 Certificate Exchange Messaging，引用的是仍处于草案阶段的 CEM 文档。不能使用 CEM 时，人工交换必须在激活前保证密钥完整性并完成认证。初始获取可以使用 Well-Known URI，但请求者必须被认证，访问也必须只授权给合法交易伙伴。

颁发者签名能暴露证书被篡改，却不能决定谁有权下载、它属于哪一条关系、用于入站还是出站。自签名证书尤其需要带外确认指纹，才可进入生产。

因此，激活凭证至少应保存：名称的精确大小写、关系标识、方向、签名或加密用途、指纹、序列号、算法、有效期、信任方式、交换来源、批准人、激活时间、重叠窗口与回滚密钥。草案要求过期、吊销或不受信任的证书立即产生明显错误；但一张未过期且受信的证书仍可能被配置给错误伙伴。

MDN 证明的边界

发送方保存原消息、Message-ID 和 MIC；接收方处理后返回 MDN。发送方可以验证 MDN 签名、核对 Original-Message-ID，并比较返回 MIC 与先前保存的摘要。RFC 8098给出现行 MDN 框架。

草案把签名与 MIC 核对后的结果称为“non-repudiation of receipt”。本文不把这一术语扩张为跨法域的法律判决，也不重写旧文已经拥有的“送达不等于业务接受”主题。这里的问题发生得更早：用于验证回执的那把公钥，凭什么被认定为当前伙伴的授权公钥？

证据链应该逐层前进：HTTP/TLS 连接；名称解析与反射；证书路径、期限与密钥检查；本地伙伴授权；消息或 MDN 签名；Message-ID/MIC 关联；MDN 处置；下游 EDI 接受；商业结果。任何一层都不应冒充下一层。

冻结的第 03 版已经包含主要证书控制，因此不能声称第 04 版才突然发明这些规则。第 04 版的 HTML 与 XML可用于核对结构，却不能证明任何部署或事故。

这也改变了审计提问。审计员不应只问“证书是否有效”，还应要求重建当时生效的伙伴行：谁接收了密钥、通过什么渠道核对、谁批准、哪一刻切换、旧钥何时失效。只有能重建这条时间线，成功的密码学检查才有可归属的组织语境。

来源与限制

资料包包括第 04 版文本、HTML、XML，Datatracker 页面、API、历史，第 03 版，RFC 4130、RFC 8098、RFC 8551、RFC 8615、RFC 5652、RFC 5280、CEM 草案、RFC 9110、RFC 9525 与 RFC 8446。领导力分析另参考 Lu Heng 关于运行代码优先、现实层与符号权力及最小初始规范的文章。资料不支持关于具体产品、部署、攻击、事故或司法结论的主张。