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.
OCSP, or the online certificate status protocol (OCSP), is an internet protocol through which web browsers determine the revocation status of SSL/TLS certificates installed on websites. Although SSL/TLS certificates come with their validity period, they need to be revoked under certain situations.
Messages communicated via OCSP are encoded in ASN. 1 and are usually communicated over HTTP. The "request/response" nature of these messages leads to OCSP servers being termed OCSP responders. Some web browsers (Firefox) use OCSP to validate HTTPS certificates, while others have disabled it.
Then, every time a client opens the website, the server is ready with updated data of the security certificate. OCSP stapling is trustworthy because the CA that initially issued the server certificate sends a signed, time-stamped response to the request. Therefore, the client can fully trust the response.
Why would you use OCSP stapling? This simple addition to your website's SSL certificate improves both security and performance. This in turn provides trust in your website and end user confidence in using your site.
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...
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With