摘要
- RFC 9919 允许预生成的 OCSP 响应经客户端、代理和服务端缓存重复分发,但明确指出 HTTP 头没有密码学保护,只能作为缓存指引。
- 接受一份响应需要核对目标证书、验证签名及签名者授权,再用准确的本地时钟判断签名内的
thisUpdate与nextUpdate区间。 - 新鲜的
good只是一项有边界的撤销状态证据;它本身不证明证书确曾签发、整体有效、拥有应用权限或产生了业务结果。
命中缓存,不等于重新询问
高吞吐 PKI 不可能让每个客户端、每次连接都迫使 OCSP 响应器即时签一份新答案。RFC 9919 允许响应预先生成、在网络中缓存,并让较短请求使用 HTTP GET。由此得到的成本优势很直接:少一次往返,少一轮签名,减少带宽,也避免大量客户端在同一时刻冲击响应器。
问题在于,日志里常把“缓存对象可复用”和“状态证据仍有效”都写成“fresh”。前者是 HTTP 分发判断,后者是 OCSP 证据判断。Expires、ETag、Cache-Control 可以告诉代理何时复用或更新对象,却没有包含在 OCSP 签名里。RFC 9919 因此要求客户端只把这些字段当作缓存指引,最终依靠签名响应内部的值。
缓存没有因此变得不可信或无用。它只是承运者。对象经由哪个节点到达,可以影响速度和可用性;它不能改写谁签了状态、状态针对哪张证书、状态在什么时间范围内成立。
三个时间不是同一个时间
thisUpdate 表示响应器在何时知道该状态是正确的;nextUpdate 表示何时或在何时之前会有更新信息;producedAt 表示响应在何时被签名。预生成场景中,三者尤其不能合并成一个“响应时间”。
RFC 6960 原本允许预生成响应。RFC 9919 为高吞吐配置强制要求 nextUpdate,因为可缓存的状态必须有签名内的截止边界。客户端要检查该字段存在,并确认当前 GMT 时间落在 thisUpdate 与 nextUpdate 之间。越过 nextUpdate 后,响应应被视为陈旧;为了处理微小时钟差异,可以配置有限容差,但容差仍是一项需要记录的本地政策。
于是,时钟质量进入安全路径。快时钟会过早关门,把仍然新鲜的响应拒绝掉,造成可用性故障;慢时钟会把已过期的 good 继续当作可用,而更新响应可能早已是 revoked。两种情况下,签名都可能完全正确。密码学能保护字节,却不能校准客户端拿来比较的时间。
RFC 9919 不要求所有请求都依赖 nonce。客户端在适用条件下不能仅因响应缺少预期 nonce 就拒绝,而要退回基于时间的检查。这让准确时钟、签名时间窗与容差设置共同成为控制面,而不是三个分散的实现参数。
max-age 分散流量,nextUpdate 终止证据
RFC 9919 特意把 HTTP max-age 放在 thisUpdate 之后、nextUpdate 之前。客户端可以在签名状态真正到期前开始更新,响应器也必须在这个较早节点前准备新响应。热门证书的客户端便不必在截止秒同时回源。
这是一种负载整形,不是另一层签名。代理修改 HTTP 头时,OCSP 签名字节可以毫无变化。无论外层如何标示,客户端都不应在签名 nextUpdate 之后继续依赖缓存响应。若代理卡住了过期对象,客户端可发起绕过缓存的重试;该动作是寻找新对象,不是让旧对象重新有效。
TLS 携带 OCSP 响应也遵循同样边界。附带响应能减少一次 HTTP 会话,甚至让客户端在无法直接访问响应器时完成检查,但握手并不会为那份响应续期。目标证书、签名者、状态与时间窗仍属于响应自身。
successful 与 good 也要分开
顶层 OCSPResponseStatus 的 successful 表明响应器能够依据权威记录作答;单张证书的结果才是 good、revoked 或 unknown。把 successful 当成证书“良好”,会在解析的第一步就扩大证据。
即使得到 good,RFC 6960 给出的最低含义仍很窄:在相应条件下,没有处于有效期内、具有所查询序列号的证书被撤销。它不必然证明这张证书曾经签发,也不必然证明生成响应时证书正处于有效期。证书路径、名称、用途和应用授权仍需别的检查。
一个可复核的收据应保存目标 CertID、响应哈希、签名者与授权链、签名算法、每证书状态、producedAt、thisUpdate、nextUpdate、客户端比较时刻、时钟偏差与容差、nonce 行为,以及 HTTP age、max-age、Expires、ETag 和是否绕过缓存。应用最后是否接受、交易是否完成、服务是否生效,应另列记录。
RFC 9919 同时要求新客户端在 CertID 中使用 SHA-256,并让仍兼容 RFC 5019 的 SHA-1 客户端尽快迁移。响应器可在旧客户端尚存时同时分发两种形式;当实际请求群体不再需要 SHA-1,就没有理由继续保留。这是一项客户端群体迁移信号,但不能代替对签名时间窗和撤销处理的核验。
来源
- https://www.rfc-editor.org/rfc/rfc9919.html
- https://www.rfc-editor.org/rfc/rfc6960.html
- https://www.rfc-editor.org/rfc/rfc5019.html
- https://www.rfc-editor.org/rfc/rfc5280.html
- https://www.rfc-editor.org/rfc/rfc9111.html
- https://www.rfc-editor.org/rfc/rfc9110.html
- https://www.rfc-editor.org/rfc/rfc8954.html
- https://www.rfc-editor.org/rfc/rfc9846.html
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
会员简报
档案背景详情
使用相应会员等级登录,即可解锁完整简报与来源注释。
仅限 Strategic Circle
Strategic Circle
所有读者均可浏览。加入并登录后可解锁档案简报。
加入 Strategic Circle仅限 Leadership Alliance
Leadership Alliance
符合条件的 IP 资产所有者和管理层可登录查看 Leadership Alliance 简报。
加入 Leadership Alliance

