Status

NSS
Libraries
P1
enhancement
RESOLVED DUPLICATE of bug 110161
16 years ago
14 years ago

People

(Reporter: Stephane Saux, Assigned: Wan-Teh Chang)

Tracking

x86
Windows 2000

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
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.
(Reporter)

Updated

16 years ago
Blocks: 110161

Comment 1

16 years ago
An OCSP cache is bug 91532.
(Assignee)

Comment 2

16 years ago
Target 4.0, priority P1.
Priority: -- → P1
Target Milestone: --- → 4.0
(Assignee)

Comment 3

15 years ago
Changed the QA contact to Bishakha.
QA Contact: sonja.mirtitsch → bishakhabanerjee
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).
Severity: normal → enhancement

Updated

14 years ago
Depends on: 91532
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 ***
No longer blocks: 110161
Status: NEW → RESOLVED
Last Resolved: 14 years ago
No longer depends on: 91532
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.