摘要

  • IESG 于 2026 年 9 月 2 日启动 draft-ietf-lamps-csr-attestation-29 的最后征求意见，意见截止 9 月 16 日；它正在按 Proposed Standard 审议，并非已批准的 RFC。
  • 草案为 PKCS#10、CRMF 证书请求定义 ASN.1 容器，可携带一项或多项 Evidence、Endorsement 或 Attestation Result；容器不是统一的信任结论。
  • CA/RA 可以用这些材料判断签发策略，也可以直接丢弃。若采用，就仍须负责公钥绑定、平台关系与新鲜度判断。
  • 硬件、补丁和设备归属信息可能敏感，草案不建议把证明复制进公开证书。因此，仅看有效证书不能知道私下执行了哪项核验。
  • 可在受保护系统中保存一份签发证据凭据，把 CSR、核验与证书连起来，同时不公开设备明细。这是 Daniel Kade 的建议，不是 IETF 要求。

证书只展示决定的终点

审计人员可以验证证书签名、有效期和信任链，却不一定能判断这张证书的请求中是否带有远程证明。即便带有，也看不出材料是否被读取、由谁评估、使用什么策略、是否满足新鲜度要求，还是在签发前被忽略。

IESG 的 9 月 2 日公告要求在 9 月 16 日前提交实质意见。Datatracker 文档页目前标为 In Last Call，IANA 复核仍为待办；历史记录显示 9 月 6 日分配了 ARTART 复核。这些事实说明审议正在进行，不代表已经批准、部署或审计过任何 CA。

第 29 版草案定义 AttestationBundle，其中可以有多个证明声明，也可以附带帮助验证声明的证书。声明可能是 Attester 生成的 Evidence、Endorsement，也可能是 Verifier 形成的 Attestation Result；具体格式既可以标准化，也可以是专有格式。

PKCS#10与 CRMF分别提供证书请求结构。新草案解决的是怎样把附加材料装进去，而不是替所有 CA 决定怎样判断。一个字段可以被正确解析，不等于它已经通过业务或安全策略。

第 28 版和官方 28→29 差异还限定了新闻的新意：第 29 版主要做澄清和引用更新，签发证据与公开证书之间的边界并非本版才出现。本次事件是它进入 IETF 范围的最后征求意见。

收到材料不等于使用材料

草案明确给 CA/RA 留下选择。它可以核验声明，以确定某项签发策略是否满足，或者多个策略中的哪一个满足；它也可以不处理而丢弃附加信息。接受或要求远程证明的 CA 应当在 Certification Practice Statement 中说明条件。

这里至少有三个不同状态：请求方提交了什么、签发系统实际判断了什么、证书最终公开了什么。CSR 是输入记录，CA 工作流是裁决记录，证书是输出凭据。把输出倒推成裁决，会制造并不存在的可见性。

RFC 9334 的 RATS 架构正好解释这层分工。Verifier 按 Evidence appraisal policy 评估证据并生成结果；Relying Party 再按自己的策略使用结果作出特定决定。密码学上有效的证明结果不会自动携带“应当签发”的命令。

CA/Browser Forum 代码签名基线要求说明了为什么签发者会关心私钥是否在合适的硬件加密模块中生成、保存和使用，也列出可接受的核验路径。但要求页面不能证明某张证书用了哪种方法；IETF 草案也不是 CA 合规审计报告。

多个真声明仍可能拼错对象

草案举出一个组合场景：一项声明证明密钥对生成于 HSM，一项声明证明某平台归企业所有，另一项声明证明某平台处于已知良好状态。三项声明各自都可能正确，却未必说的是同一套系统。

CA/RA 必须确认第一项关联 CSR 中的公钥，后两项关联容纳同一 HSM 的平台。仅统计三项签名有效，不能完成这次关系连接。草案还说，证明列表中至少一项“应当”包含与 CSR 目标公钥进行密码学绑定的证明；“至少一项”不能自动把其他声明也绑定到同一设备。

新鲜度也不是有无字段这么简单。CA/RA 可以忽略过期材料，或无法确定新鲜度的材料。新鲜度草案第 08 版规定通过 CMP、EST 或 CMC 请求 nonce 的方式，却把需要几个 nonce、怎样传给 Attester、由谁生成以及其他新鲜度方法留在范围之外。

所以，核验记录至少要说明哪项证据消费了哪次挑战、接受窗口是什么、关系连接是否成立，以及哪个策略作出判断。否则，各个零件都可能有效，最后的决定却不可复核。

隐私不等于忘掉决定

远程证明可能包含硬件细节、补丁水平或设备归属。第 29 版因此“不建议”CA 把它复制进公开证书；如确需再发布，应检查并删除敏感信息。CRMF 的扩展变体也因硬件环境的隐私风险，不建议用于 X.509 证书。

这个限制有充分理由。证书会广泛传播、缓存和长期保留。把设备快照塞进证书，会让一次短时、特定目的的评估变成长期可关联的公开标识。

更合适的是双层签发凭据。受保护部分连接 CSR 摘要与证书序列号或指纹，记录证明格式、隐私安全的证据摘要、Attester、Verifier、CA/RA 角色、公钥与平台连接结果、新鲜度方法、证据评估策略和签发策略版本、每项声明被处理或丢弃的状态、签发决定、责任人和时间。

公开部分只需给出凭据标识、证书引用、范围有限的结论、适用策略指针和纠错渠道。设备清单、测量值、归属文件和参考值继续受访问控制。授权审计者可按保存规则调阅。

这份凭据是我的治理建议，不在草案或 RFC 9334 中。它不强迫 CA 使用远程证明，不为隐藏材料背书，也不指控任何机构丢弃过应核验的材料。它只保证：当公开证书按设计不带完整档案时，签发理由仍可被有权者重建。

The Policy Mirror要求寻找把事实变成权力的开关；此处就是把私下评估转成 CA 签名的策略连接。Running Code Primary进一步要求运行证据。CPS 说明预期，证书说明已经签发，只有执行凭据说明这一次究竟走了哪条路径。

来源

  1. IESG 最后征求意见公告
  2. CSR 远程证明 Datatracker 页面
  3. 文档历史
  4. 第 29 版
  5. 第 28 版
  6. 官方 28→29 差异
  7. RATS 架构 RFC 9334
  8. PKCS#10，RFC 2986
  9. CRMF，RFC 4211
  10. 证明新鲜度草案第 08 版
  11. CA/Browser Forum 代码签名基线要求
  12. Lu Heng — The Policy Mirror
  13. Lu Heng — Running Code Primary