摘要

  • RFC 10004 把 CMC 要求分别放在实体、客户端、服务器、终端实体、注册机构和认证机构六个范围内；同一组件可以同时占据多个范围。
  • 可审计的合规证据应绑定软件版本、角色图、条件功能、算法策略、配置时期、具体交易路径和结果，而不是停在一个产品级勾选框上。

验收报告写着：请求格式通过，HTTP 传输通过，必需算法通过。上线图纸却多出一层注册机构，负责身份验证和部分密钥的持有证明。报告没有造假，但它回答的是旧问题。

这是一个用于说明边界的假设场景，不对应任何真实产品。RFC 10004 最重要的管理含义，正是合规问题必须先确定“谁以什么身份工作”。

CMC 表面上是客户端与服务器关系。最简单时，终端实体是客户端，认证机构是服务器。加入注册机构后，RA 面对申请者是服务器，面对 CA 又是客户端。系统还可以串联多个 RA，并按申请内容选择路径；标准明确指出，并非每个 RA 都会看到每份申请。

于是，一张“支持 CMC”的产品表无法覆盖实际责任。RFC 10004 把要求分为所有实体、所有客户端、所有服务器、EE、RA 和 CA 六类。组件在哪一条连接上工作、是否承担密钥生成或身份验证、是否执行委托 POP，都会改变适用集合。

RFC 10002 定义消息与控制，RFC 10003 定义传输；RFC 10004 才把实现义务分配给不同角色。RFC Editor 页面和勘误检索共同界定审计所依据的准确版本。

所有实体都必须支持 Full PKI Request、Simple 和 Full PKI Response、CRMF 证书请求以及 HTTP 传输；服务器还应支持 Simple PKI Request 与 PKCS 10。但共同底座之上，是一张带脚注的条件矩阵。

例如，CA 如果被设计为与 RA 协作，某些控制就从一般能力变成必需能力。EE 若工作在由 RA 做身份验证或密钥生成的环境中，对 Response Body 的要求也会上升。Encrypted POP 与 Decrypted POP 又取决于是否使用密钥协商、硬件密钥能否签名，以及 POP 是否委托。

这意味着，软件没有升级，合规范围也会变化。只要拓扑、角色或功能开关改变，就可能激活此前未纳入测试的义务。把上次验收结果复制到新架构，是把实现能力误写成运行事实。

算法要求同样不能脱离路径。RSA-SHA256、AES、规定参数的 AES-GCM 和 RSA 密钥传输构成基础；DH、PBKDF2、AES Key Wrap 与 HMAC-SHA256 在特定条件下进入要求。RFC 5652给出 CMS 基础，RFC 5754规定 SHA-2，RFC 5084处理认证加密。

库存表能证明库中有某种算法，却不能证明某次申请选择了它、参数正确、控制由应负责的节点处理，或后续机构接受了结果。能力、启用状态、实际执行和最终授权必须分开记录。

POP 把责任边界暴露得最清楚。CA 在签发前必须强制验证持有证明，但可在限定情形下委托 RA。RFC 6955给出 DH POP 方法。审计记录要回答：哪一个机构、对哪份申请、依据哪个委托策略、用了什么方法，并把什么证据交给下一层。

合规还带有时间版本。RFC 10004 取代 RFC 5274，并吸收 RFC 6402 的更新，把基础算法要求推进到 SHA-256 时代。为了向后兼容，服务器可以继续提供旧算法，但标准建议借助 CMC 请求识别应迁移的证书。兼容是待退出的群体，不是无限期默认值。

证书签发后，证据链还没有结束。RFC 5280规定 PKIX 证书和路径验证。CMC 合规不能证明申请人依法拥有某个名称，不能证明依赖方接受证书链，也不能代替应用授权和服务结果。

Heng Lu 的现实层次要求把标准、能力、配置、执行、签发和使用拆开。运行代码优先把可观察行为置于标签之前。最小初始规范则把共同承诺限制在可验证核心，让未来选择留给承担后果的运营者。

因此，真正有用的产物是一份“角色绑定收据”：组件和软件版本、每条连接上的客户端/服务器方向、EE/RA/CA 身份、RFC 与勘误基线、条件功能、启用算法、策略和配置版本、申请实际经过的 RA、处理过的控制、POP 决策、响应与证书接受状态。看不到的环节必须标成缺口，不能用绿色标签补齐。

来源