540906 - Certum CA OCSP uses Trusted Responder mode

Status: RESOLVED WORKSFORME

(CA Program :: CA Certificate Root Program, task)

Description

[Kathleen Wilson]

Enforce OCSP in the Firefox browser, then go to 
https://www.certum.pl/certum/main.xml

Resulting Error: An error occurred during a connection to www.certum.pl. 
The signer of the OCSP response is not authorized to give status for this 
certificate. (Error code: sec_error_ocsp_unauthorized_response)

This issuer's OCSP responder uses a self-signed OCSP responder
certificate, which does not meet the criteria of RFC 2560, except when used as
the exclusive trusted locally-configured OCSP responder, designated by the
relying party.

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 Certum'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 Certum.

OCSP URL (http://ocsp.certum.pl) is included in all of the SSL certificates chaining to Certum's root that is included in NSS.

Comment 1

[Kathleen Wilson]

Detailed explanation of the problems with Trusted Responder mode; courtesy of
Nelson:

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 has two uses (that I can see):

1) 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.

2) 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.

We've seen numerous public CAs misunderstand this.  They seem to think
that the standard allows 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.

So, we see public CAs (typically for small countries) that setup 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, the scheme that is being proposed by these various CAs
only works for users who are only going to visit web sites that get get their
certificates from that 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.

Comment 2

[Kathleen Wilson]

This is NOT a duplicate of bug #378673, which was closed in 2007 as invalid.

This bug is specific to Certum's OCSP service for their root that is currently included in NSS.

The only way the current OCSP service can work is if the users have configured Firefox to use Certum's OCSP responder cert as their trusted OCSP responder. It is highly unlikely that users have done this.

Comment 3

[Kathleen Wilson]

Certum has updated their OCSP service. I have confirmed that it works within the Firefox browser when OCSP is enforced.