1. Introduction

The Transport Layer Security (TLS) Extension [RFC6066] framework defines, among other extensions, the Certificate Status extension (also referred to as "OCSP stapling") that clients can use to request the server's copy of the current status of its certificate. The benefits of this extension include a reduced number of roundtrips and network delays for the client to verify the status of the server's certificate and a reduced load on the certificate issuer's status response servers, thus solving a problem that can become significant when the issued certificate is presented by a frequently visited server.

There are two problems with the existing Certificate Status extension. First, it does not provide functionality to request the status information about intermediate Certification Authority (CA) certificates, which means the client has to request status information through other methods, such as Certificate Revocation Lists (CRLs), introducing further delays. Second, the current format of the extension and requirements in the TLS protocol prevent a client from offering the server multiple status methods.

Many CAs are now issuing intermediate CA certificates that not only specify the publication point for their CRLs in a CRL Distribution Point [RFC5280] but also specify a URL for their OCSP [RFC6960] server in Authority Information Access [RFC5280]. Given that client-cached CRLs are frequently out of date, clients would benefit from using OCSP to access up-to-date status information about intermediate CA certificates. The benefit to the issuing CA is less clear, as providing the bandwidth for the OCSP responder can be costly, especially for CAs with many high-traffic subscriber sites, and this cost is a concern for many CAs. There are cases where OCSP requests for a single high-traffic site caused significant network problems for the issuing CA.

Clients will benefit from the TLS server providing certificate status information regardless of type, not just for the server certificate but also for the intermediate CA certificates. Combining the status checks into one extension will reduce the roundtrips needed to complete the handshake by the client to just those needed for negotiating the TLS connection. Also, for the Certification Authorities, the load on their servers will depend on the number of certificates they have issued, not on the number of visitors to those sites. Additionally, using this extension significantly reduces privacy concerns around the clients informing the certificate issuer about which sites they are visiting.

For such a new system to be introduced seamlessly, clients need to be able to indicate support for the existing OCSP Certificate Status method and a new multiple-OCSP mode.

Unfortunately, the definition of the Certificate Status extension only allows a single Certificate Status extension to be defined in a single extension record in the handshake, and the TLS protocol [RFC5246] only allows a single record in the extension list for any given extension. This means that it is not possible for clients to indicate support for new methods while still supporting older methods, which would cause problems for interoperability between newer clients and older servers. This will not just be an issue for the multiple status request mode proposed above but also for any other future status methods that might be introduced. This will be true not just for the current PKIX infrastructure [RFC5280] but also for alternative PKI structures.

The solution to this problem is to define a new extension, "status_request_v2", with an extended format that allows the client to indicate support for multiple status request methods. This is implemented using a list of CertificateStatusRequestItemV2 records in the extension record. As the server will select the single status method based on the selected cipher suite and the certificate presented, no significant changes are needed in the server's extension format.