OCSP stapling details and doubts

Question

I am trying to figure out the details of OCSP stapling and how it works. As often the best way is, I started Wireshark and made a simple request to a server that has OCSP stapling enabled.

Can anyone please clarify the below doubts I have?

1. Request
   Client Hello extension data:

   In Wireshark I see the client hello extension as below

   Extension: status_request
     Type: status_request (0x0005)
     Length: 5
     Certificate Status Type: OCSP (1)
     Responder ID list Length: 0
     Request Extensions Length: 0
   

   I understand the presence of the first two fields. But why do we need the next 3 (Certificate Status Type, Responder ID list Length, Request Extensions Length) as they are 0 anyways. What kind of data can they contain and how is the server supposed to process data in these fields?

2. Response
   Part of the response is:

   Certificate Status Type: OCSP (1)
   ResponseType Id: 1.3.6.1.5.5.7.48.1.1 (id-pkix-ocsp-basic)
   BasicOCSPResponse
   tbsResponseData
   responderID: byKey (2)
     byKey: f2026c2ad426a4a59cb2505b3962446034151e5b
   

   What are the fields byKey and ResponseType ID? And how is the client supposed to process the same? Does the client need to match the Certificate status type with what was sent in the client hello?

3. Chain?
   I understand that revocation checks need to be done for all certificates in the chain. How does this fit in with stapling? We are doing a handshake only once. Is the server responsible to maintain revocation status of all certs in the chain?

Answer 1

#1. Request

1. [...] why do we need the next 3 (Certificate Status Type, Responder ID list Length, Request Extensions Length)[...]?

The status_request is defined in RFC 6066, section 8. Certificate Status Request.

---

Certificate Status Type: OCSP (1)

Boring. It's the only defined value right now. Field is for future extensibility, I guess.

---

Responder ID list Length: 0

From the RFC:

In the OCSPStatusRequest, the "ResponderIDs" provides a list of OCSP responders that the client trusts. A zero-length "responder_id_list" sequence has the special meaning that the responders are implicitly known to the server, e.g., by prior arrangement.

And this is meant especially for "constrained clients", like embedded systems, that only know a handful of CAs.

---

From the RFC:

"Extensions" is imported from [RFC5280]. A zero-length "request_extensions" value means that there are no extensions (as opposed to a zero-length ASN.1 SEQUENCE, which is not valid for the "Extensions" type).

Dunno. I don't really understand the imported from RFC5280. But I guess it might refer specifically to section 5.2.1 of that RFC5280. But I don't really understand that section either.

#2. Response

2. [...] What are the fields byKey and ResponseType ID? [...]

The byKey field is just an identifier for the OCSP responder. So that the client can decide if he trusts that responder/signer or not. And it can be either byName or byKey

Does the client need to match the Certificate status type with what was sent in the client hello?

Absolutely. But there only is one type defined at the moment, no anything other than OCSP (1) is going to be undefined/wrong/useless anyway.

#3. Chain?

I understand that revocation checks need to be done for all certificates in the chain. How does this fit in with stapling?

AFAIK: not too well. But there is an effort to introduce "Multi-Stapling" (from 2013):

With the necessary support in TLS clients and servers it would be possible to use OCSP stapling for the intermediate CA certificates, too. Checking this information in connection with a stapled OCSP response is referred to as “multi-stapling.”

Multi-stapling should have been as simple as defining a new method for the Certificate Status extension and including that method in the list of methods supported by the client. Unfortunately, that was not the case.