499311 - Cache OCSP status of intermediate certificates persistently (across application restarts)

Status: RESOLVED DUPLICATE of bug 48597

(NSS :: Libraries, enhancement)

Description

[Paul Tiemann]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4
Build Identifier: 

Perhaps NSS could cache OCSP responses (at least for intermediate certificates) across application restarts.  

Right now, it seems like Firefox always re-fetches the OCSP status for intermediate certificates in addition to end-entity certificates, causing in most cases 2 OCSP requests for each handshake when a  end-entity certificate's parent(s) also provide an OCSP responder.

Perhaps an OCSP status could be persistently cached for 12 or 24 hours maximum if the certificate itself is more than 30 days old?  

Some people are in the habit of closing and re-opening their applications multiple times per day, and I think this usage pattern creates a lot of superfluous OCSP checking of intermediate certificates and even end-entity certificates who may have just been checked by the same computer 20 minutes ago.

Reproducible: Always

Steps to Reproduce:
1. Start Firefox, go to https://www.digicert.com
2. Restart Firefox, go to https://www.digicert.com again

Actual Results:  
Four total OCSP requests will be made.  One for the end entity certificate and one for the intermediate certificate.

Expected Results:  
The OCSP responses from the first hit to https://www.digicert.com should be trustworthy enough to rely on them for the next 12 to 24 hours, at least for the intermediate certificate.

Comment 1

[Gervase Markham [:gerv]]

Confirming as enhancement request. Moving to NSS; my first impression would be that this would be an NSS feature. But the NSS developers might think differently :-)

Gerv

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

Comments:
1. NSS only queries OCSP for CA certs when the EE cert is an EV cert.  
For non-EV certs, NSS only queries OCSP for the EE cert itself.

2. If you think lack of a persistent cache for OCSP responses is a problem,
imagine how it will be when CRL fetching via CRL DP is enabled, and the CRLs 
thus fetched are not persistently stored!  ( Bug 489347 )

Comment 3

[Paul Tiemann]

Gerv, thanks for steering this to the right place.  I'm sorry I didn't notice NSS in the products drop down earlier. 

Nelson, thanks for the clarification about EV and non-EV OCSP behavior.  I can understand the case for being more thorough with EV status checking.  Having said that, it would be very nice if CA certificates' status could still be cached across restarts, especially if OCSP stapling can only send the EE certificate's status (I admit I haven't read the RFC closely enough to know.)

I had a question about your #2 item.  I was under the impression that CRL fetching is only attempted when A) a certificate only has a CRL DP and no OCSP responder defined or B) when an OCSP responder can't be reached, as a failback mechanism.  Are CRLs going to be actively used instead of OCSP in some cases?

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Paul,  Presently, no version of Firefox (including FF 3.5 release candidates
to date) attempts to automatically fetch CRLs on demand from URLs in CDP extensions.  I anticipate that will change in some FF 3.5.x release.

There is no standard that specifies correct behavior for an implementation 
that supports both CRL fetching and OCSP, when it encounters a cert with URLs 
for both.  But I expect that Firefox will work as you have envisioned.  

I also hope that Firefox will eventually do revocation checking on the entire
cert chain for non-EV and EV certs alike, but I am not aware of any plans for
that to be implemented.

Comment 5

[Kai Engert [:KaiE:]]

This bug requests to cache OCSP responses persistently, and this request is a duplicate of bug 48597.