Recently I set up a PingDom monitor to track the overall performance of the various OCSP responders out there, PingDom is limited to doing GETs and cannot parse the responses from the responders but it’s a fair mechanism to look at response time.

These tests run from a number of different global locations and are averaged together, the locations change but the same locations are used for each set of tests so again this seems fair.

I decided to use the Google logo as my control test, as it is about the same size as a larger OCSP response, after about a month of monitoring this is what I saw:

As you can see the fastest responder is over four times slower than the Google logo, far from acceptable.

When looking at the individual responses and their responses this is what I saw:

• Very few responders are using CDNs, AnyCast or other techniques to globally distribute responses.
• Only a handful of responders have multiple DNS entries for failover scenarios.
• Quite a few responders are not following the HTTP caching header requirements in RFC 5019.
• Most responders are not sending CA signed responses which reduce the response size significantly (down to 471 bytes), in my opinion a OCSP responder should do this for all pre-produced responses.
• Some responders are returning Unknown for out of scope responses, this really isn’t safe for unauthenticated requests as it exposes the responder to resource consumption denial of service for against the signing keys.
• Response freshness ranges from 6 hours to 14 days, I am quite sure the six hour responses are failing for a very large % of the internet community due to time skew; 4 days appear to be optimum.

These are all fairly easy things to address and I believe it’s reasonable for responders to get down to response times that are consistent with the control test above.