As discussed via e-mail a few weeks ago, the OCSP support in NSS will need to be
enhanced in order to be practical for servers. Here are some of the enhancements
that we would need : 1) OCSP checking of the complete cert chain from bottom to
top. This is needed in order to ensure the security at all levels. I realize it
will impact performance, so perhaps there should be an option to do OCSP
checking only of the leaf, or the full chain. 2) some sort of cache. This is an
absolute must, in order to cut down on the number of outbound connections to the
OCSP responder. Especially if the full cert check is checked. We don't want to
have all the server threads stuck doing OCSP, which would basically mean a down
server. 3) flexibility in configuration of OCSP checking. This is especially
true for network timeouts for all outgoing connections, as well as the
management of errors. I'm sure there is more to be added to this requirement
list. I just want to make sure everybody is aware of what needs to be done
before OCSP can become a reality in servers.
This is migrated from bugsplat 528337
I'll add that the client would need some or most of these improvements.
An OCSP cache is bug 91532.
Target 4.0, priority P1.
Changed the QA contact to Bishakha.
Regarding the "top to bottom" comment, I don't think it makes sense to use
OCSP to attempt to validate root CA certs. IINM, the Root CA typically
issues the cert for the CA's OCSP responder. If the root CA is not valid
then neither is the OCSP response from an OCSP response whose cert is
issued by that root CA.
Since this bug seems to serve as a collector for OCSP enhancement requests,
here are some more that I received by email.
1. Implement the Nonce extension to OCSP requests as a configurable option,
and verify them in responses if the request had a nonce. This avoids
replay attack. This should be configurable.
2, Test responses for "freshness". Examine the timestamp in the response
to ensure that it is not older than some configurable value. This is
intended to limit vulnerability to replay of responses, but to allow
responders to intentionally replay their own responses for short periods
of time, saving them a lot of repeated signing for responses to frequently
requested cert requests. They can only do that for requests that don't use
the Nonce extension. The freshness test feature in a client is not
necessary if Nonce extensions are used, but never hurts.
3. OCSP response cache expiration times. Cached OCSP responses should
expire at a configurable time after the date/time in the response's
time stamp, rather than the date/time at which the repsonse was received,
if the time stamp is older than the reception time (which should be common).
This bug seems to be YET ANOTHER OCSP tracking bug.
Other OCSP tracking bugs include 157555 and 110161.
This bug just isn't needed.
So, I am remving its dependency links, and
marking it a dup of 110161.
*** This bug has been marked as a duplicate of 110161 ***