Open Bug 48597 Opened 24 years ago Updated 2 years ago

OCSP needs offline cache (persistent on-disk)

Categories

(NSS :: Libraries, enhancement, P3)

enhancement

Tracking

(Not tracked)

People

(Reporter: lord, Unassigned)

References

(Blocks 2 open bugs)

Details

Attachments

(1 file)

You can't use OCSP when you're on an airplane.  We need an OCSP cache in the 
OCSP library, and that cache needs to be active in PSM.
When do you want this by?  I can pretty much guarantee there isn't enough time 
to get this into PSM 1.3.  (This is all NSS work and the person who could get 
this done very quickly is on maternity leave.)
Changing QA contact to nitinp
QA Contact: lord → nitinp
Mass reassigning nitinp's bugs to me.
QA Contact: nitinp → junruh
Target -> 2.1
Target Milestone: --- → 2.1
Keywords: nsenterprise
This requires NSS changes.  Until NSS commits to giving us the offline cache, we
can't specify a Target Milestone for PSM.  Setting to Future.
Target Milestone: 2.1 → Future
Depends on: 91532
removing nsenterprise keyword from PSM bugs with target milestone of future.
Keywords: nsenterprise
Mass assigning QA to ckritzer.
QA Contact: junruh → ckritzer
QA Contact: ckritzer → junruh
Blocks: 157555
Severity: normal → enhancement
Component: Daemon → Client Library
QA Contact: junruh → bmartin
I'm having problems with offline caching also.  (1) camino automatically looks
on the web for a photo even when it is in cache.  currently it is unable to load
a page that loads fine in IE 6.2 under VPC; because it won't automatically call
to the cache to pick up the picture and instead is running the server ragged
looking for it.  (2) i should have the option to be able to check for page
updates automatically, never, or every visit to page.  (3) i should be able to
check cache contents and empty what i feel i don't need.  

bottom line is i am displaying a blank page right now on one site where i can
obtain an image through IE 6.2 under VPC.  

OS:  OS X 10.2 (Jaguar) for Mac, PowerMac 933, 1.5G RAM
mozilla_bug@hotmail.com, this bug is about caching of OCSP responses. OCSP is a
protocol used to validate certificates. This bug has nothing to do with caching
of URL objects in the browser, as you inferred in comment #8 . 
Depends on: ocspcache
No longer depends on: ocspcache
Blocks: ocspdefault
No longer depends on: 91532
*** Bug 91532 has been marked as a duplicate of this bug. ***
Mass reassign Javi's old PSM bugs to nobody
Assignee: javi → nobody
QA Contact: bmartin → nobody
Target Milestone: Future → ---
Product: PSM → Core
Such a cache should probably be implemented at the NSS level.
-> NSS
Assignee: nobody → nobody
Component: Security: UI → Libraries
OS: Windows NT → All
Product: Core → NSS
QA Contact: nobody → libraries
Version: psm1.3 → trunk
This RFE apparently seeks to impose an additional set of requirements on
the (not yet written) OCSP cache.  It apparently requests that the cache
contents be perpetual surviving browser restarts, and not expiring while
the browser is "offline".  

We could do that in several different ways, some of which are:

a) Implement the cache in a disk file, so that all cached responses are
always stored on disk.  
b) have NSS have a API for retrieving the cache contents (from memory)
so tht the appliation can fetch the cache contents and write them to disk.
That would also require the complementary API by which the memory cache
contents could be reloaded from values stored on disk.  

One way, storage of the cache contents becomes NSS's responsibility.
The other way, they are the appliation's responsiblity.  
There are many pros and cons to both approaches.  

Applications seem to always want to know all names of all files used by NSS,
not allowing the file names to be "private" to NSS.  That is an argument for
putting the burden onto the applications.  

Appliations are generally slow to implement new features.  This is why file
name changes (e.g. from cert7 to cert8) are so disruptive.   This is an 
argument for giving NSS full control.  

I would like to continue the path on which we started in NSS 3.0, which is
that the appliation names a directory for NSS to use for all its files and 
DBs, and NSS uses whatever file names (and subdirectory names) it wishes to
use in that directory.   But OTOH, perhaps this "offline  cache" feature is
a "browser only" feature, in which case it makes sense to put the 
implementation burden on the browser.  
Such an offline cache only makes sense if the application actually saves content from https in its cache.

If the application really does that - another approach is to provide a clear UI override, stating "OCSP not possible because you're offline".

Not sure if it makes really sense to have such an OCSP offline cache. The user will only be ever able to view pages that have been viewed before, and where the page's cert was valid at the time of viewing. Caching the related OCSP response does not really improve that in any way.

I think this request is more of the kind "allow to view my cached pages, even if OCSP is switched on".
In mozilla browsers, the decision of whether or not to cache https content
in the disk cache is stored in a user settable pref named  browser.cache.disk_cache_ssl .  I don't know how commonly it is enabled.
(In reply to comment #15)
> In mozilla browsers, the decision of whether or not to cache https content
> in the disk cache is stored in a user settable pref named 
> browser.cache.disk_cache_ssl .  I don't know how commonly it is enabled.

It seems to be disabled by default.
For all people who are confused like me about the difference of this bug and bug 205406 (OCSP local cache), see bug 205406 comment 9.
Hardware: PC → All
Summary: OCSP needs offline cache → OCSP needs offline cache (persistent on-disk)
Assignee: nobody → agl
Attached patch patch v1Splinter Review
I would want to review this again myself before flagging it r?, but it appears to work in testing and it's certainly ready for a design review if anyone cares to take a look.
Adam, thanks for working on this.

One design decision is whether we should store the OCSP responses
in NSS's certificate database  or in a separate cache file.  If in a
separate file, should that file be located in the NSS config directory
($HOME/.pki/nssdb) or a directory specified by the application?

I had always assumed that we would cache OCSP responses in our
cert db as that's where we're storing CRLs.  But for fast lookup and
frequent updates, perhaps a dedicated cache file is more appropriate.
I think a cache in the NSS config directory to be shared by all apps
is good, especially given our goal of promoting NSS as a system
library, but we'll need to deal with multiprocess access issues.

Bob, Nelson, what do you think?
Status: NEW → ASSIGNED
The current function protocol contains an argument for the path to the file because I couldn't find any way to get the certdb directory from within NSS. If there is an easy way to do this, then I would prefer to keep the OCSP cache in $CERTDB/ocspcache or some such.
Blocks: 803582

The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.

Assignee: agl → nobody
Status: ASSIGNED → NEW
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.