110166 - OCSP improvement.

Status: RESOLVED DUPLICATE of bug 110161

(NSS :: Libraries, enhancement, P1)

Description

[Stephane Saux]

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.

Comment 1

[John G. Myers]

An OCSP cache is bug 91532.

Comment 2

[Wan-Teh Chang]

Target 4.0, priority P1.

Comment 3

[Wan-Teh Chang]

Changed the QA contact to Bishakha.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

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

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

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 ***