1. Introduction (简介)

Transport Layer Security (传输层安全协议, TLS) Extension (扩展) [RFC6066] 框架定义了许多扩展, 其中包括 Certificate Status extension (证书状态扩展) (也称为 "OCSP stapling" (OCSP装订)), 客户端可以使用该扩展请求服务器当前证书状态的副本。该扩展的好处包括减少客户端验证服务器证书状态所需的往返次数和网络延迟, 并减少证书颁发者状态响应服务器的负载, 从而解决了当颁发的证书由频繁访问的服务器提供时可能变得严重的问题。

现有 Certificate Status extension 存在两个问题。首先, 它不提供请求有关中间 Certification Authority (认证机构, CA) 证书状态信息的功能, 这意味着客户端必须通过其他方法请求状态信息, 例如 Certificate Revocation Lists (证书吊销列表, CRLs), 从而引入进一步的延迟。其次, 扩展的当前格式和 TLS 协议中的要求阻止客户端向服务器提供多种状态方法。

许多 CA 现在颁发的中间 CA 证书不仅在 CRL Distribution Point (CRL分发点) [RFC5280] 中指定了其 CRLs 的发布点, 而且还在 Authority Information Access (授权信息访问) [RFC5280] 中指定了其 OCSP [RFC6960] 服务器的 URL。鉴于客户端缓存的 CRLs 经常过时, 客户端将受益于使用 OCSP 访问有关中间 CA 证书的最新状态信息。对颁发 CA 的好处不太明显, 因为为 OCSP 响应者提供带宽可能成本高昂, 特别是对于拥有许多高流量订阅者站点的 CA, 并且这一成本是许多 CA 关注的问题。在某些情况下, 对单个高流量站点的 OCSP 请求给颁发 CA 造成了严重的网络问题。

客户端将受益于 TLS 服务器提供证书状态信息, 无论类型如何, 不仅针对服务器证书, 而且针对中间 CA 证书。将状态检查合并到一个扩展中将把客户端完成握手所需的往返次数减少到仅协商 TLS 连接所需的次数。此外, 对于认证机构, 其服务器上的负载将取决于它们颁发的证书数量, 而不是这些站点的访问者数量。此外, 使用此扩展显著减少了客户端向证书颁发者告知他们正在访问哪些站点的隐私问题。

为了无缝引入这样的新系统, 客户端需要能够表示对现有 OCSP Certificate Status 方法和新的 multiple-OCSP (多OCSP) 模式的支持。

不幸的是, Certificate Status extension 的定义仅允许在握手中的单个扩展记录中定义单个 Certificate Status extension, 并且 TLS 协议 [RFC5246] 仅允许扩展列表中的任何给定扩展有单个记录。这意味着客户端无法在支持旧方法的同时表示对新方法的支持, 这将导致新客户端和旧服务器之间的互操作性问题。这不仅是上述提出的 multiple status request (多状态请求) 模式的问题, 而且对于将来可能引入的任何其他状态方法也是如此。这不仅对当前的 PKIX 基础设施 [RFC5280] 如此, 对替代 PKI 结构也是如此。

解决此问题的方案是定义一个新的扩展 "status_request_v2", 其扩展格式允许客户端表示对多种状态请求方法的支持。这是使用扩展记录中的 CertificateStatusRequestItemV2 记录列表来实现的。由于服务器将根据选择的密码套件和提供的证书选择单一状态方法, 因此不需要对服务器的扩展格式进行重大更改。