Question

As far as I know, OCSP only provides explicit means for requests and responses to be signed ([RFC2560, page 7] for requests, and [RFC2560, page 8] for responses), but it does not make any mention about encryption. Is it typical (or even possible, which I suppose that of course it is) to run OCSP over SSL/TLS to also guarantee its confidentiality?

Thanks.

Was it helpful?

Solution

Yes, it is possible using SSL/TLS. But consider this:

When certificates include a cRLDistributionPoints extension with an https URI or similar scheme, circular dependencies can be introduced. The relying party is forced to perform an additional path validation in order to obtain the CRL required to complete the initial path validation! Circular conditions can also be created with an https URI (or similar scheme) in the authorityInfoAccess or subjectInfoAccess extensions. At worst, this situation can create unresolvable dependencies.

Taken from RFC5280, Section 8. This section addresses the problem using https for CRL distribution points. But you will have the same issue using SSL/TLS for OCSP requests: you have to check the validity of the server certificate...

OTHER TIPS

In the appendix of the RFC2560 is the following written:

A.1.1 Request [...] Where privacy is a requirement, OCSP transactions exchanged using HTTP MAY be protected using either TLS/SSL or some other lower layer protocol.

But the most OCSP-Responder only provide HTTP without TLS/SSL.

It is definitely possible, but it's not typical. If you are requesting the status of a host certificate, the OCSP request is unlikely to reveal anything an eavesdropper doesn't already know—namely, the host that you are trying to authenticate.

For S/MIME email or other applications, OCSP requests could be a lot more sensitive, because they would support organizational analysis. Using HTTPS transport could be be a good idea there.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top