0

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?

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

  1. [...] 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.

  • The " imported from RFC5280..." is saying that the specification of "Extensions" and "Extension" are defined in RFC5280, close to the end of section 4.1. "Extensions" is defined as a SEQUENCE of at least one "Extension", therefore a zero-length "Extensions" (ie an Extensions with no Extension element) is not valid. – vincentleest Oct 3 '16 at 14:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.