6.5 Certificate Revocation (证书吊销)

以下考虑和建议代表了关于证书吊销的当前技术水平, 尽管对于检查公共公钥证书 [RFC5280] 的吊销状态的问题, 还没有完整和高效的解决方案:

尽管证书吊销列表 (Certificate Revocation Lists, CRLs) 是分发吊销信息的最广泛支持的机制, 但它们存在已知的扩展性挑战, 限制了它们的有用性 (尽管有诸如分区 CRLs 和增量 CRLs 之类的解决方法)。
在 Web 浏览器的配置数据库中嵌入吊销列表的专有机制无法扩展到少数最常用的 Web 服务器之外。
在线证书状态协议 (On-Line Certification Status Protocol, OCSP) [RFC6960] 既存在扩展性问题, 也存在隐私问题。此外, 客户端通常 "软失败", 意味着如果 OCSP 服务器没有响应, 它们不会中止 TLS 连接。(但是, 如果 OCSP 响应者被下线, 这可能是避免拒绝服务攻击的解决方法。)
TLS 证书状态请求扩展 ([RFC6066] 的第 8 节), 通常称为 "OCSP 装订" (OCSP stapling), 解决了 OCSP 的操作问题。但是, 在存在 MITM 攻击者的情况下, 它仍然是无效的, 因为攻击者可以简单地忽略客户端对装订 OCSP 响应的请求。
[RFC6066] 中定义的 OCSP 装订不扩展到证书链中使用的中间证书。尽管多证书状态扩展 (Multiple Certificate Status extension) [RFC6961] 解决了这个缺陷, 但它是一个没有太多部署的最近添加的内容。
CRLs 和 OCSP 都依赖于与互联网的相对可靠的连接, 这可能对某些类型的节点 (例如, 需要建立安全连接以便首次启动的新配置设备) 不可用。

关于公共公钥证书, 鉴于当前的技术水平, 服务器应该支持以下内容作为最佳实践, 并作为可能的未来解决方案的基础:

OCSP [RFC6960]
[RFC6066] 中定义的 status_request 扩展和 [RFC6961] 中定义的 status_request_v2 扩展 (这可能使与最广泛范围的客户端的互操作性成为可能。)
[RFC6961] 中定义的 OCSP 装订扩展

本节中的考虑不适用于使用 DANE-TLSA 资源记录 [RFC6698] 向客户端发出信号, 表明服务器认为哪个证书有效且适合用于 TLS 连接的场景。