VeriSign has spent a lot of time and effort recently ensuring that not only
do our OCSP services work, but that they will continue to work as the load
increases. Clearly there is no excuse for any CA, especially VeriSign, to
have a faulty OCSP implementation...especially if they are including the AIA
extensions in certs they issue.
I think mozilla will turn OCSP back on by default in some forthcoming release. Maybe soon, who knows?
When we first enabled OCSP, years ago, we had a lot of unexpected problems due to OCSP responders from various CAs returning no responses at all or returning false negative responses. This caused many mozilla users to feel that https had become unusable.
In haste to correct this, we implemented a preference to disable OCSP entirely, and we set that preference to disable OCSP by default. (The preference may have existed before then, but we turned off OCSP then.)
OCSP has remained off by default for years since then. We felt we could not re-enable it until the vast vast majority of CAs' OCSP responders all worked, since it was a global preference.
If we had not been so pressed to restore https service, we might have chosen to implement an OCSP preference on a CA by CA basis, rather than as a global preference. Had we implemented it as a CA-by-CA preference, OCSP would have remained enabled for many CAs during the past few years.
I feel that cert validation is a very important part of PKI, and thus would rather that it be turned on by default. I agree that CRL's in this case are not the way to go...and this is why I suggested that OCSP (and not CRL's) be the default validation mechanism.
I would say mozilla does not have a default revocation mechanism now.
Whether CRLs are used or not is already user controlled on a CA by CA basis, and is not used until the user enables it for a CA. OCSP is globally enabled and disabled, but when enabled, it is only used when the appropriate cert extensions are present.
So, once OCSP is re-enabled by default, perhaps it will then be said that OCSP is the default revocation mechanism. I've been running with it on for quite a while now, and it seems OK to me.
This seems like overkill to me. If the platform can determine the status
via one of the mechanisms (or via a local cache), then there is no reason to
re-ask for the same info via another mechanism.
* If there is both an AIA and CDP extension, the browser must send an OCSP request first. If OCSP fails, then it should then fall back to using a CRL.
I think this is fine, as long as you don't automatically hit wire to fetch a
CRL if the cert indicates OCSP is available. I would still suggest that if
there is no locally cached (non-expired) revocation info for a particular
cert in the local caches, that OCSP be tried first...and then CRL's as a
last resort only if OCSP fails.
Alex, there's an important detail or two about how CRLs work in mozilla that may set your mind at rest.
Mozilla NEVER fetches CRLs during the act of cert chain validation, AFAIK.
Cert chain validation uses CRLs in a CRL cache, and that cache is updated based on NextUpdate dates, not based on cert chain validations. If the CRL is missing from the cache when a validation occurs, the validation doesn't trigger a fetch right then.
CRLs for a CA are fetched automatically once the user "primes the pump"
by manually downloading the first one. The user must do this via a link
on a web page or a typed URL, IINM, because AFAIK, there is no button to download the first CRL. Downloaded CRLs are kept in an on-disk database,
so that they do not have to be refetched every time mozilla is restarted.
Once a CRL is downloaded, new CRLs are fetched as the previous CRL nears its "nextUpdate" date. So, CRL fetching frequency is controlled by the CA's "nextUpdate" period, not by frequency of chain validations. Also, after the first CRL is downloaded, a button appears in the UI that allows the user to trigger an update download ahead of the next scheduled update.
This scheme allows a user to use CRLs with some CAs and not others. It was actually designed for use in servers. (NSS is used in both servers and clients, which many mozilla folks forget.)
As I understand Julien's previous answer on this topic, If a mozilla user has a CRL downloaded from a CA, and turns OCSP on, and encounters a cert from that CA that specifies OCSP, then it will check the CRL, and then if the CRL check passes, it will also check OCSP. But the CRL check wastes only browser CPU/Memory cycles, because it doesn't "hit the wire".
Great...are there plans to cache OCSP responses?
I am not presently aware of a scheduled plan to do that. I think we agree it's important for performance of both browsers and servers. But as long as OCSP remains turned off, a cache is superfluous.
My memory of this stuff isn't the best, so if someone tells me I'm misstated a detail or two above, I won't be shocked.
/Nelson Speaking only for myself, not for mozilla or AOL.
_______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
