摘要

  • RFC 10003 让 CMC 对象能够经由多种承载方式交换，却没有把任何承载方式变成证书机构的授权证明。
  • 一份文件、一次 2XX 响应或一条完整的 TCP 回复，分别只证明其所在的传输阶段已经发生。

最容易被忽略的控制面，往往恰好是默认不存在的那个。HTTP 绑定中，RFC 10003 并不要求 HTTP 认证，也不要求 cookies。它并不是忘了为证书决定补上身份层；它是在描述一个更窄的事实：客户端可以以 POST 提交 CMC 对象，服务器以 2XX 表示这次 HTTP 处理成功。传输接口保持可互操作，并不自动产生一个可以归责的决策主体。

因此，服务端返回成功与证书被签发之间不能画等号。前者告诉我们，这个接口把对象处理到了协议规定的阶段。后者需要另一个问题集来回答：哪一家 CA 或注册机构负责，哪一种本地政策适用，谁有权批准、拒绝或修改请求，以及最终是否生成了可供依赖方使用的证书。只有其中一项留下记录，不能替代其余各项。

RFC 10003 对四类承载方式给出了清晰边界。文件配置文件让一个二进制 CMC 请求或响应处于一个文件中；邮件配置文件处理其邮件承载；HTTP 以 POST 和 2XX 描述交换；TCP 直接传送二进制消息，客户端须在同一连接上收到完整响应后才发送下一项请求。它们使对象能够抵达不同的操作环境，却没有把决定权装进对象或连接里。

TCP 的顺序要求尤其值得正确解读。完整响应先于下一次请求，能够减少协议交互的歧义；已登记的 pkix-cmc TCP 服务端口能够帮助发现服务。它们对于运行可靠性很重要，但不能回答“该服务代表谁作出决定”。把端口可达、连接有序或响应完整写成授权链的一部分，正是把机械事实扩展成制度事实。

规范中的重放限制也说明了界线。CMC 的 HTTP 请求在 TLS 1.3 或 QUIC 中不得使用 0-RTT，因为 POST 不是幂等操作；具体环境可能需要重放防御。这些要求处理的是请求会不会被不恰当地再次执行，而不是谁被授权执行。安全的传输路径仍然需要独立的本地权力结构。

邮件路径提供了同样的提醒。首个 SMTP 跳点上的 TLS 不能说明后续跳点的认证或加密状况。CMS 或 S/MIME 可以保护内容的机密性；内容被保护，不等于接收方具备改变证书状态的资格。保护属性、路由属性和授权属性可以相关，但它们不是同一种证据。

最稳妥的记录方式是把“承载事实”和“决定事实”分开。前者记下对象、传输通道、时间、响应与完整性条件；后者记下责任机构、适用控制、决议与签发结果。RFC 10003 把前一类事实说得更精确，也因此更不应被拿来填补后一类事实的空白。