摘要

  • RFC 5280 的证书配置规则已经要求 CRL 签名证书包含 keyUsage 并置位 cRLSign，但旧验证步骤只说“若扩展存在则检查位值”，没有同时要求扩展本身存在。
  • RFC 10007 把 v3 证书的两项判断写完整：keyUsage 必须出现，cRLSign 必须为真。签名、名称和证书路径均正确，也不能替代这项用途授权。
  • 可审计凭据应分别保存证书版本、实际密钥、扩展是否存在、CRL 范围与时效、路径与签名结果、目标序列号结论以及旧版例外的批准者。

想象一家 CA 给同一个主体 X 发了两张证书。第一张认证密钥 A，明确写着它可以签 CRL；第二张认证密钥 B，用于日常的邮件或文档签名，没有 keyUsage 扩展。两张证书的主体名称相同，两条认证路径都能回到可信根。

现在 X 用 B 签出一份 CRL。数学没有出错：签名确实由 B 对应的私钥产生。身份字符串也没有出错：CRL 发行者仍叫 X。真正缺失的是用途授权——B 的证书从未声明 B 可以签吊销信息。

这是 RFC 10007 给出的核心场景。该标准于2026年6月发布，更新 RFC 5280，作者为 Corey Bonnell、Tadahiko Ito 与 Tomofumi Okubo，Bonnell 列在第一位。人物贡献应被准确记录，但这仍是 IETF 集体审议形成的标准，不是个人对 CA、软件厂商或依赖方的命令。

身份相同，不等于权限相同

证书常被简化成“这把公钥属于谁”。真实配置还要回答“这把公钥可以做什么”。keyUsage 不是装饰字段：当证书用于验证其他证书或 CRL 的签名时，RFC 5280 要求该扩展出现并标为 critical；cRLSign 位专门表示主体公钥可用于验证 CRL 签名。

旧算法的问题藏在一句条件语中：如果 CRL 发行者证书里有 key usage 扩展，就检查 cRLSign。有扩展而未置位会失败；扩展整个缺失时，检查却可能被跳过。结果是，明示“不具备该用途”比“没有说明用途”更严格。

安全自动化很容易落入这种结构。程序验证了一个存在字段，却没有验证该字段必须存在；验证了一个声明的值，却没有把未声明视为独立失败。最终的绿色状态看似来自更多证据，实际来自少问了一个问题。

RFC 10007 将步骤改为：如果 CRL 发行者证书是 v3，则验证 keyUsage 扩展存在，并验证 cRLSign 已置位。两个“并且”都不能省略。审计日志也不应只留下“key usage pass”，而应保留“扩展存在”与“位值为真”两栏。

v1、v2 例外必须留下来由

新规则没有要求 v1 或 v2 证书包含扩展，因为这些版本根本没有 extensions 字段。这个例外来自表示能力，而不是一般性的“缺失即许可”。若依赖方接受旧版 CRL 发行者证书，凭据必须记录证书版本、适用政策、例外所有者与复核期限。

部署迁移会因此暴露历史债务。有些 v3 发行者证书原本就是为 CRL 签署而发，却漏掉 keyUsage。遵循旧条件的软件可能一直接受其 CRL；落实 RFC 10007 的新版软件则会拒绝。同一份字节未改动的 CRL，会因验证器升级而改变结论。

这不应被草率叙述为“新标准导致故障”。更准确的说法是：升级揭示了一项过去未被检查的证书配置错误。RFC 10007 建议 CA 为 CRL 验证证书加入 keyUsage。若确实无法更改配置，PKI 的政策管理机构应要求不同用途的证书使用唯一 DN，减少同名不同权密钥被混淆的机会。

唯一名称是缓解措施，不会替旧证书补写字段，也不会自动更新依赖方。谁负责重发证书、调整分发点、升级验证器、批准临时例外，仍是本地治理问题。

通过授权关，不代表吊销结论全部成立

确认 cRLSign 只解决一个边界。验证器还要选中正确的 CRL 与发行者证书，构建路径，核查签名算法，处理分发点与 issuing distribution point 的范围，识别 indirect CRL，处理 critical 扩展，判断 thisUpdate 与 nextUpdate 的时效，并在需要时正确结合完整与增量 CRL。

最后还要查看目标证书序列号。获授权密钥签出的 CRL 可能已经过期；新鲜且签名正确的 CRL 可能不覆盖目标证书；所有结构都合法的 CRL 也可能明确报告目标已被吊销。因此“签署者获授权”不能被升级成“证书可用”“吊销服务健康”或“交易安全”。

反向推理同样危险。新版验证器因 v3 证书缺少 keyUsage 而拒绝 CRL，只能证明授权要求没有按标准呈现；它本身不证明攻击已经发生、CRL 内容伪造或密钥被盗。

Heng Lu 关于 agency 的区分在此很实用。标准作者定义共同语法；CA 决定证书配置；实现者把规则写进运行代码；政策机构决定旧版例外；业务方承担不可用或误信的后果。任何一方都不能把自己的判断悄悄借给下一方。标准作者的名字不替实现背书，签名通过也不替政策授权签字。

最小规范提供跨实现共同的两项检查，本地系统保留迁移与例外的决定权。运行代码则告诉我们某个版本的验证器实际选择了哪张证书、执行了哪些检查。只存最终布尔值，会同时丢掉规范与现实。

建立可复核的吊销验证凭据

先固定输入：目标证书、信任锚、CRL 地址与内容哈希、抓取时间、thisUpdate、nextUpdate、签名算法，以及验证软件和版本。再记录实际选中的发行者证书，包括序列号、Subject Key Identifier、相关的 Authority Key Identifier、主体 DN 与版本。

随后按顺序保存判断：路径是否成立；CRL 签名是否验证；发行者证书是否 v3；keyUsage 是否存在且为 critical；cRLSign 是否置位。若走 v1/v2 例外，应保存批准政策、影响范围、到期时间和复核者。

范围证据另存：distribution point、cRLIssuer、indirect CRL 标志、issuing distribution point、覆盖原因、完整或增量关系。目标结论再单独保存：序列号是否出现、吊销时间和原因、证据是否过期或缺失，以及应用最终采取的动作。

有了这些连接字段，版本分歧才可诊断。一组节点可能因扩展缺失拒绝，另一组仍按旧逻辑通过，第三组则选中了另一张同名证书。模糊红灯只能制造事故；精确凭据能够指出迁移边界。

最终结论应保持有限：在某时刻，某版本验证器对一份确定的 CRL 使用某张 v3 发行者证书；扩展存在且 cRLSign 为真；签名、路径、范围、时效和目标序列号分别得到各自结果。它不提供“全面可信”的徽章，却足以让安全决策承担责任。

来源