摘要

  • RFC 9919 要求符合新版轻量级 OCSP profile 的客户端，用 SHA-256 计算 CertID 中的发行者名称与发行者密钥哈希；沿用 RFC 5019 的旧客户端应尽快离开 SHA-1。
  • responder 可以为兼容性在同一 BasicOCSPResponse 中放入 SHA-1 与 SHA-256 两个 SingleResponse，运营者也可以记录客户端请求所用的哈希算法，辅助判断何时停止分发 SHA-1 版本。
  • 这类日志只看见抵达观察点的请求。客户端缓存、代理缓存、预生成响应、TLS 装订或其他 piggyback 交付、备用 responder 路径与带外约定，都可能让真实依赖没有出现在计数里。
  • CertID 的哈希算法用于识别被查询证书的发行者上下文，与 OCSP 响应的签名算法不是一回事。
  • 合理的退役需要一份可复核回执：写明分母、观察面、双响应策略、停止条件、决策人、canary、fallback、例外到期日和切换后的结果。

一条归零曲线证明了什么

它首先证明某段时间里，某套分类规则没有在某个 responder 入口识别到 SHA-1 CertID 请求。这个事实有价值，但范围很窄。把它写成“旧客户端已经全部升级”，等于把流量采集点偷偷提升成全体依赖者名册。

RFC 9919 的设计恰恰会压低直连请求。高容量环境可以预生成响应；客户端必须缓存已验证且权威的成功响应；HTTP 中间代理可以复用对象；响应也可以随 TLS 等协议交换被携带。最后一种方式让客户端不必另开一条到 OCSP responder 的 HTTP 会话。计数减少，可能来自升级，也可能来自缓存命中率提升、response lifetime 改变、装订覆盖扩大或流量被调度到另一个实例。

profile 还说明 OCSP 协议本身不通告 responder 能力。客户端可能依赖运营者之间的带外安排，判断某个服务是否按该 profile 工作。只查 responder 日志，不会自动得到这些合同、设备清单或封闭网络中的配置。

因此，零不是没有意义；零必须带上分母。没有分母，读者无法知道这是一台机器、一个区域、一个证书族，还是完整的生产面。

新旧 profile 的真正变化

RFC 5019 曾要求客户端用 SHA-1 计算 CertID.issuerNameHash 和 CertID.issuerKeyHash。RFC 9919 废止了旧 profile，并要求新版客户端改用 SHA-256。仍为兼容旧规范而使用 SHA-1 的客户端，必须在实际可行时尽快迁移。

响应端允许有计划的过渡。通常只应有一个 SingleResponse，但为提升预生成性能、缓存效率或向后兼容，可以增加元素。规范直接举例：同一响应中，一个 CertID 用 SHA-1，另一个用 SHA-256。如果没有客户端还需要 SHA-1，responder 就不应继续分发这一版本；运营者可以考虑记录请求算法，为退役决定提供依据。

“提供依据”不等于自动批准。RFC 没有给出统一的连续零天数、允许的遗留比例或全球客户端分母。它留下的是本地运营决策，而不是一个计数器触发器。

还要避免最常见的术语误读。RFC 6960 把 CertID.hashAlgorithm 定义为生成发行者名称和公钥哈希的算法，并与证书序列号共同确定查询对象。BasicOCSPResponse.signatureAlgorithm 是另一个字段。RFC 9919 第 8.7 节甚至明确说，SHA-1 用于这里的 CertID 计算本身不是密码学安全问题；继续保留它的代价，是互操作软件必须维持更多实现复杂度与潜在攻击面。

所以，本次退役处理的是识别字段的兼容分支。不能把它宣传成“停止 SHA-1 响应签名”，也不能用签名算法库存替代客户端 CertID 库存。

先设计观察矩阵

第一列应列出全部 responder 实例、入口 hostname、区域和流量路径。第二列列出证书人口与客户端群组。第三列记录每条路径是否能看到直接请求、缓存再验证、装订交付、离线使用与 fallback。第四列标注证据缺口及其负责人。

测量窗口还要与系统周期相称。如果一个预生成响应的有效期长于观察期，缓存中的旧客户端尚未到再次请求的时刻。只在一个低流量证书族上跑 canary，也不能代表另一个企业设备群。规范没有替运营者选择窗口；运营者需要用最大响应寿命、刷新节奏、发布周期和合同清单解释自己的选择。

分母至少应回答：哪些客户端本来有机会进入日志，哪些被客户端缓存抑制，哪些由代理或 CDN 代取，哪些通过 TLS 装订取得响应，哪些可能访问其他 responder，哪些受带外 profile 安排约束。不可观察的部分应被明确写成排除项，而不是被算作 SHA-256。

一份可以关闭例外的回执

退役回执应写明范围与决策 owner；观察点和分母；当前 SHA-1 例外清单；单响应或双响应政策；缓存与装订覆盖；测量区间和停止条件；canary 的人口、期限及退出门槛；失败时恢复双响应或旧路径的 fallback；以及例外若未续批就自动失效的日期。

切换后还要补上结果：是否重新出现 SHA-1 请求，是否增加 unauthorized 或其他错误，是否发生验证失败，fallback 是否被启用，影响了哪些证书族和用户场景。只有批准而没有结果，仍然是一张计划，不是完成回执。

IETF 负责定义可互操作的协议规则，但不会替某个运营者承担生产失败。软件、服务承诺和客户后果属于本地控制面。让兼容分支无限存在是没人负责；让它因一条安静曲线突然消失，同样是没人负责。

来源