摘要

  • RFC 10002 所说的私钥持有证明，只证明终端实体持有并能使用与公钥对应的私钥。它不自动证明申请者身份，也不授予证书名称、用途或签发资格。
  • CMC 将身份证明与私钥持有证明分别承载，再要求确认两者来自同一实体。注册机构只能在已签名请求之外增加控制层，认证机构仍须依据自己的政策批准、修改、等待处理或拒绝。
  • 可追责的登记记录应依次保留原始请求、持有证明、身份证据、防替换关联、各层注册机构操作、认证机构决定、CMC 回应、最终证书，以及安装、路径验证和吊销状态；任何一个“通过”都不能覆盖其他状态。

一条写着“POP 验证通过”的记录很容易让人安心。PKCS #10 请求中的公钥没有被替换，签名确实由对应私钥生成。这是有价值的密码学事实，却不是一张已经批准的证书。

它没有回答申请者究竟是谁，也没有回答申请者能否使用所填的主体名称或 Subject Alternative Name。它没有说明注册机构是否有权添加扩展，没有说明认证机构采用了哪版政策，更没有证明证书已经送达设备并被业务系统接受。

2026年7月发布的 CMC 三份 RFC，恰好为这些界线提供结构。RFC 10002 规定基于 CMS 的证书管理消息；RFC 10003 规定 HTTP、文件、邮件和 TCP 等传输方式；RFC 10004 规定不同 CMC 代理类别的合规要求。Joseph Mandel 与 Sean Turner 是三份文件的共同编辑。它们还依赖 PKCS #10、CRMF、CMS 与 X.509 体系，因此不能把 CMC 写成 Turner 一人的发明。

IETF Datatracker 截至2026年9月1日的公开资料显示，Sean Turner 从 IETF 34 开始参与，署名或共同署名超过50份 RFC，曾在2007年至2014年担任 Security Area Director，并担任过或正在担任多个工作组主席。这些经历说明他为何长期出现在安全标准中，却不赋予他对某一次证书申请、某家注册机构或认证机构的实际审批权。

请求签名保护的是原话

PKCS #10 把公钥、主体和属性放入一个签名对象。验证签名可以发现内容被改动，也能阻止攻击者把自己的公钥换进别人的已签名请求。它由此提供一种签名型私钥持有证明。

RFC 2986 对认证机构的描述却还有后续动作：认证申请实体、验证签名，并在请求符合要求时构造证书。“符合要求”不是签名算法得出的结论，而是认证机构依据政策作出的判断。名称归属、用途、有效期、证书模板与额外证明都可能影响结果。

RFC 10002 用 Proof-of-Possession（POP）概括私钥持有证明。CMC 涉及签名、直接挑战响应、间接证明、发布与证明书等不同形式，并不要求每种交换都使用所有形式。无论形式怎样变化，证明范围没有随之扩大：它只说明终端实体能够使用对应私钥。

被窃取的私钥照样能生成正确签名；合法设备也可能绑定错误的资产编号；能管理密钥的人未必有权申请雇主或服务的名称；新密钥还可能与过期库存记录组合。此时 POP 可以完全正确，签发决定仍然必须为否。

真正危险的是系统替证明升级含义。“私钥可用”被改写成“身份成立”，随后变成“名称获准”，最后成为“证书可签发”。每次升级都需要新证据，不能借用前一层的绿色状态。

身份与钥匙之间的连接也要验

RFC 10002 单独定义 Proof-of-Identity。需要在请求中携带身份证明时，Simple PKI Request 不应使用；Full PKI Request 可以采用共享秘密生成的身份见证值、已有证书，或双方约定的其他机制。

分开承载便于区分证明，却也产生替换风险。假如甲提供了有效身份，乙提供了有效私钥，系统不能把两份分别正确的结果拼成“甲持有乙的钥匙”。因此，CMC 明确要求保证身份证明与 POP 由同一实体提供。共享秘密与主体名称的匹配、见证值计算、已有证书关联，都是为这次连接服务。

连接本身应当有一条独立记录：两侧标识是什么，覆盖了哪些字节，由谁验证，采用何种防替换方法，结果与时间为何。界面上并排的两个“通过”不能证明它们属于同一申请者。

共享秘密还暴露了协议之外的治理问题。RFC 10002 不负责其带外分发。如果秘密发给错误设备、在多个资产间复制，或在重试中反复使用，正确见证值只证明有人知道这段秘密，并不能把最初分发过程变得可靠。记录必须写清证明方法及其上限。

注册机构可以加层，不能改写签名历史

CMC 把终端实体、注册机构（RA）与认证机构（CA）分开。终端实体拥有密钥对并申请证书；RA 可以做本地核验、批量整理、路由、密钥生成或归档、扩展处理；CA 负责签发证书。同一节点在面对终端实体时可能是服务器，面对 CA 时又是客户端，这只是协议方向，不是权力转移。

最重要的证据边界是已经签名的内层请求。RA 若直接修改 PKCS #10 或 CRMF 请求，会让签名与 POP 失效。它需要改字段或增加扩展时，应在外层 CMC 控制中提出。多个 RA 可以形成多层嵌套，每一层都留下自己的请求者与签名。

如此才能同时回答两件事：终端实体原本要求什么，后来又是谁提出了变化。如果只保存最后版本，就会把中间人的操作伪装成申请人的原意。

X.509 扩展尤其容易产生这种错觉。申请可以列出希望获得的名称、密钥用途、策略或其他扩展。RFC 10002 要求服务器处理定义好的扩展，却没有要求把每一项原样放进证书。服务器可以修改，但不能反转原意。最终证书是 CA 评估模板与政策后的结果，不是申请表的机械复制。

只留最终证书，会丢掉最初意图；只留原始请求，会丢掉谁有权改变它。完整记录应同时保留签名请求、每层外部控制、修改内容、政策依据、签名者、CA 评估的模板与返回证书。

HTTP 完成与证书签发不在同一时钟

RFC 10003 允许 CMC 通过 HTTP、文件、邮件和 TCP 传输。HTTP 使用 POST 与规定的媒体类型。HTTPS 可以保护通道，但传输 RFC 并不要求所有 CMC 客户端都实现 HTTP 身份认证。TLS 通道、HTTP 认证、CMC 身份证明和 POP 解决的是不同问题。

状态码也只能解释本层。HTTP 2xx 说明 HTTP 处理成功；内层 CMC 回应仍可能处于等待状态，或报告 badIdentity、popRequired、popFailed 和不支持扩展。把 2xx 当作签发成功，就像把快递签收当成文件获批。

即使 CMC 回应成功，也应核对具体证书：公钥是否与请求一致，主体、名称、用途、策略和有效期究竟是什么，是否送到预定终端。没有最终字节的“完成”只是状态标签。

RFC 10004 的合规要求同样不能越级。一套实现满足某类 CMC 代理要求，只说明它具备规定能力；这不证明特定组织已正确部署，也不证明某次请求符合政策，更不证明市场采用。

签发以后又有一条证据链

证书签发不是业务授权的终点。RFC 5280 的路径验证会处理信任锚、证书链、名称、策略、约束、有效期与吊销信息。之后还有证书交付、设备安装、私钥持续保管，以及业务系统自己的访问规则。

一张正确签发的证书可能没有送到设备；已安装证书可能找不到对应私钥；有效路径可能落在业务不接受的信任锚；身份验证成功，也不表示该身份获得某项操作权限。明天的吊销状态还可能改变今天的判断。

Heng Lu 的“运行代码优先”要求主张回到可重复验证的证据。在登记阶段，保留请求字节、POP、身份证据、两者关联、RA 层、CA 政策与回应。在运行阶段，保留证书字节、密钥匹配、安装目标、路径结果、状态来源与本地授权。

可辩护的记录至少包含：申请者与时间；所请求的公钥和字段；POP 方法、验证者与结果；身份证明方法及限制；身份到 POP 的关联；每层 RA 修改及签名；CA 与政策版本；CMC 状态；确切证书；交付、安装、验证；吊销、替换与纠正。

Turner 与 Mandel 共同编辑的 CMC 标准之所以有价值，不是因为它让一份私钥证明通行到底，而是因为它给不同的证明与权力留下了各自的位置。

来源