Summary

  • RFC 10003 为 CMC 规定 HTTP、文件、邮件与 TCP 四种传输机制。它们产生的是载体证据；真正的申请结果在 CMC 的 PKI Response 中。
  • HTTP 2XX、邮件被接受、文件出现或 TCP 写入完成，都不能单独证明 CA 或 RA 批准了申请、签发了预期证书，也不能证明证书已经安装和使用。
  • Daniel Kade 建议建立“CMC 传输—决定凭据”，将有界传输记录、经验证的响应、待定状态、签发证书指纹和部署观察逐层关联，同时不保存申请密钥、正文或敏感身份材料。

两张回执不能合并

自动化平台最喜欢单一状态。请求发出，服务器回包，界面变绿，工单关闭。证书申请也很容易被塞进这条流程：只要 HTTPS 返回 200，就把状态写成“已签发”。

RFC 10003 让这种快捷判断失去借口。它是一份 CMC 传输规范，覆盖 HTTP、文件、邮件和 TCP。RFC 10004 进一步要求所有 CMC 实体都实现 HTTP，其他传输可以选用。标准因此解决了客户端与服务器如何识别载荷、怎样包装、用什么顺序交换的问题。

但证书操作的结果由 RFC 10002 定义。Full PKI Response 可以表示成功、失败、待处理、部分完成、不支持、需要确认，或需要继续进行持有证明。延迟签发可能需要多个往返。传输回合结束，业务事务完全可能仍然开放。

第一张回执来自载体：它说消息到了哪里、什么时候到、返回了什么字节。第二张回执来自应用协议：它说申请是否获准。两者相关，却不能互相替代。

2XX 的权限边界

RFC 10003 要求 HTTP 客户端用 POST 提交请求，服务器对成功响应使用 2XX。规范也规定了二进制正文和媒体类型：Full PKI Request 使用 application/pkcs7-mime，参数为 smime-type=CMC-Request；Full PKI Response 使用 smime-type=CMC-Response。简单请求与简单响应另有标识。

这些要求能产生清晰的运行证据：目标 URI、方法、时间、状态码、Content-Type、TLS 策略引用以及请求和响应的哈希。运营者可以据此证明某个端点接收了请求，并按 HTTP 规则交回了响应。

这份证明没有越权解释响应正文。一个 2XX 可能承载 failed、pending 或 partial 的 CMC 状态。HTTP 服务成功完成了“返回响应”这件事，CA 却可能拒绝申请，或者尚未作出最终决定。

反过来，非 2XX 也未必等于“CA 拒绝”。错误可能发生在代理、路由、HTTP 认证、媒体类型检查或服务器入口，CMC 决策逻辑甚至没有看到申请。准确状态应当是“未观察到 CMC 决定”，而不是给 CA 编造一项拒绝。

待处理是一项后续义务

pending 不是速度较慢的成功。RFC 10002 的 PendInfo 包含令牌和建议再次查询的时间，申请方有责任轮询；partial 也要求继续处理尚未满足的部分。如果使用事务标识，它要保留到 Full PKI Response 完成事务。

这意味着证据系统必须容纳未完结状态。第一次响应可以证明传输成功并确认“仍待处理”。下一次查询要以同一事务、受保护的待定令牌和新的传输记录相连。如果令牌丢失、查询未发生或批量申请只完成一部分，系统应暴露缺口，而不是依靠时间推移把状态自动变成成功。

重试还可能改变事实数量。POST 不是幂等操作，因此 RFC 10003 禁止支持 TLS 1.3 或 QUIC 的 CMC 实现使用 0-RTT early data。响应丢失后盲目重发，可能产生两次投递。没有事务标识、nonce 与正文哈希，调查者就难以区分恢复性重试、重放和新的授权申请。

四种载体，各有一种假确定性

文件传输要求每个文件只包含一个二进制请求或响应，并建议使用固定扩展名。出站目录中出现 .crq，最多证明某个进程写出了文件；入站出现 .crp，也不能证明接收方已经解析、验证或批准其中内容。扩展名是格式提示，不是裁决印章。

邮件传输规定 MIME 包装、文件名、媒体类型，并给出 base64 示例。Message-Id、SMTP 接受或邮箱送达属于邮件系统的证据，CMC 状态仍需从正文取得。安全覆盖也会随跳点改变。RFC 10003 特别提醒：应用到最初邮件提交代理之间使用 TLS，不代表后续 SMTP 中继都经过认证和加密。支持条件合适时可请求 REQUIRETLS，但某个中继不支持扩展时也可能造成不投递。

TCP 传输不再增加包装，直接发送二进制 CMC 消息。pkix-cmc 注册在 5318 端口，客户端必须收到完整响应后，才能在同一连接上发送下一个请求。连接建立与 socket 写完仍然不等于响应有效。

四种载体无需产生完全相同的日志。它们必须遵守同一条边界：只能证明自己观察到的传输事实，不能替 CA/RA 宣布结果。

消息保护不能抹掉路径

CMC 借助 CMS 结构提供完整性、认证或机密性；传输侧还可能使用 HTTPS、IPsec、EnvelopedData 或 AuthEnvelopedData。多层保护是好事，但每层回答的问题不同。

TLS 可以保护连接不被窃听，却不能证明申请者有权取得某个名字，不能证明 RA 完成身份核验，也不能证明 CA 同意特定证书模板。一个经验证的 CMS 对象可以证明正文未被篡改，却不能单独说明它经过哪个端点、哪段中继失败，或者某个响应对应哪次重试。

RFC 10003 还说明，CMC 客户端不必支持 HTTP 认证或 Cookie，因此服务器不能依赖这些机制一定存在。初始信任如何建立，签发政策由谁掌握，仍是传输规范之外的架构问题。

所以“安全送达”必须拆开说。是 TLS 通道通过验证，还是 CMS 消息通过验证？申请者的权限获确认了吗？CMC 决定是什么？返回的证书是哪一张？设备实际启用的是不是这一张？准确语言本身就是控制。

一份传输—决定凭据

我建议为自动化申请建立CMC 传输—决定凭据。这是 Daniel Kade 的治理设计，不是 RFC 10003 或 IETF 增加的要求。

第一层记录载体。HTTP 部分包括端点身份、方法、时间、状态码、媒体类型、TLS 策略引用，以及请求与响应的有界哈希。邮件部分记录提交消息标识、目标、观察到的交接状态和中继保护范围。文件或 TCP 部分记录受控通道、方向、时间与对象哈希。正文、口令、密钥和敏感拓扑无需进入凭据。

第二层记录应用解析：简单或完整请求/响应、事务标识、涉及的 body part，以及完整性与认证结果。收到字节但无法解析，不是“决定未知后的成功”，而是证据停在传输层。

第三层保留原始状态语义。pending 关联受保护的令牌引用、建议查询时间和最终解决它的轮询。partial 清楚标识已完成与未完成部分。失败信息只保留运营所需的有界原因，避免把敏感身份资料扩散到普通仪表盘。

第四层只在确有签发对象时存在。它将证书指纹、签发者、序列号、公钥引用、名称集合和有效期连接到申请和决定。它不假设响应中的证书顺序，也不会因为出现自签名证书就自动把它当作信任锚。

最后一层记录部署。安装、激活与依赖方接受是独立事实。CA 可以正确签发，而设备装错链、继续使用旧证书，或根本没有激活新凭据。外部探测应说明实际呈现的证书指纹与观察时间。

按“最后一个已证事实”运营

成熟的界面不只显示“完成/失败”，而是告诉运营者最后证到哪一步：“POST 已接受”“CMC 响应已验证”“申请待处理”“证书已签发”“指纹已安装”“新证书已被连接使用”。每个动词有自己的责任人和时钟。

监控重点是断裂的连接：2XX 正文无法解析；CMC 失败被汇总成传输成功；待定令牌没有后续查询；相同正文出现在不同事务；返回证书与预期密钥或名称不符；签发后没有安装记录；服务仍呈现上一张证书。

分母也要正确。不是“多少 HTTP 请求变绿”，而是“多少已发起的证书事务能够说明最后一个已证阶段，并能找回支持它的证据”。

RFC 10003 让 CMC 消息有了标准道路。运行代码不应因此获得把抵达写成批准的权力。

资料来源

  1. Lu Heng：数据主权的技术现实与实践现实
  2. Lu Heng：BTW Media 为何存在
  3. Lu Heng：运行代码优先
  4. RFC 10003：CMC 传输协议
  5. RFC 10002：Certificate Management over CMS
  6. RFC 10004：CMC 一致性要求
  7. RFC 5273：旧版 CMC 传输协议
  8. RFC 5967：application/pkcs10 媒体类型
  9. RFC 8551：S/MIME 4.0 消息规范
  10. RFC 9110：HTTP 语义
  11. RFC 9205：基于 HTTP 构建协议
  12. RFC 9325：TLS 与 DTLS 安全使用建议
  13. RFC 8446：TLS 1.3
  14. RFC 9000：QUIC
  15. RFC 8689：SMTP REQUIRETLS 选项
  16. RFC 3207：基于 TLS 的安全 SMTP