CA/OCSP-TrustedResponder
When an issuer's OCSP responder uses a self-signed OCSP responder certificate, it does not meet the criteria of RFC 2560, except when used as the exclusive trusted locally-configured OCSP responder, designated by the relying party. This is known as Trusted Responder Mode.
While Trusted Responder Mode is supported by Firefox. It makes the one trusted responder be the ONLY EXCLUSIVE OCSP responder that Firefox will trust, and hence configuring Firefox to use one CA's OCSP responder as the trusted OCSP responder is ONLY helpful to users who are ONLY going to visit sites whose certs were issued by that CA.
Details
The OCSP RFC allows the relying party (the USER, not a CA) to create an OCSP server of his own, to which he will send all of his OCSP requests. This OCSP responder will sign its own responses, and the relying party will check that the responses have the correct signature by checking them with the responder's own certificate, which the relying party has explicitly configured and trusted for that purpose.
This appears to have two uses:
- As a proxy, e.g. in a corporate environment: a company can set up its own OCSP responder which acts as an OCSP proxy server. All the clients (relying parties) inside the company send their OCSP requests to the company's responder, which then can check its own store (cache) of previously received responses, and if the response is not there, it can forward the request on to the real CA's real server, then create and sign its own response and send that back to the relying party (intranet browser). This has numerous benefits for the corporate intranet environment, and NSS and Firefox support it.
- In a completely closed PKI environment, where the relying parties (browsers) ONLY deal with certs all coming from CAs subordinate to one root CA, it might make sense to have a single OCSP responder that issues responses for all the CAs that are subordinate to that one root, and have all relying parties send their requests to that one OCSP responder.
In both of the above cases, the decision to use a special OCSP responder is a decision made by the relying party, NOT by the CA that issues the certs. When the Relying Party chooses to use a special OCSP responder that he has designated and trusted, he is choosing to use his own configured OCSP responder INSTEAD OF the OCSP responder at the URL that is given in the certificates being checked. When he chooses that, ALL his OCSP requests go to that designated trusted OCSP responder, regardless of the OCSP URL in the certificate itself. The Relying Party's OCSP request includes a copy of the original OCSP URL (if any) from the certificate being checked, which helps an OCSP proxy to go ask the right server if needed.
But when using a designated trusted OCSP responder, the relying party does not use the OCSP URL directly. Therefore, that trusted OCSP responder MUST be able to respond to ALL the OCSP requests that will be generated by the relying party for ALL the certificates about which the relying party will ask.
Firefox's OCSP configuration DOES permit the user to configure it with a URL of an OCSP responder to which Firefox will then send ALL of its OCSP requests. When such a configuration is made, the user must also tell it which certificate to use to verify all the OCSP responses from that responder. The certificate must have previously been imported. Presently, the cert must be marked as a trusted issuer, or it will not appear in Firefox's certificate selection UI. This is a bug in the certificate selection UI.
A common misunderstanding occurs when a CA interprets the standard as allowing the relying party to configure his software with an OCSP responder certificate to be associated with a particular OCSP responder, but then the relying party software will continue to send OCSP requests to the responder named in the certificate in the normal fashion, and when the response is received, the software will check it against the configured responder certificate.
As a result of this misunderstanding, public CAs (typically for small countries) set up their own OCSP responder and expect the user to configure his browser to use their responder as his trusted OCSP responder. That is possible, but if done, the user will be sending ALL of his OCSP requests to that responder, and we have not yet seen ANY public CA's OCSP responder that is willing and able to act as a proxy responder for other CAs' certificates.
So, in practice, trusted responder mode only works for users who are only going to visit web sites that get get their certificates from one CA - in other words, only in the small closed environment where all the certs come from that one CA. Such an environment may exist in corporations or governments, but not in the homes of the average Mozilla browser user.
