Andrews, Rick wrote, On 2008-05-28 11:22:
> I hope I'm sending this to the right group. Can someone describe for me
> (or point me to documentation) how Firefox 1, 2, and 3 handle revocation
> checking, in terms of CRLs and OCSP? What I'm interested in is:
> - whether revocation checking is turned on by default
> - whether CRL checking can be enabled but only for certain CRLs and Cas
> - whether FF can be told to follow the CDP or AIA extension in the cert
> - any other wrinkles
>
> I'm running FF2 now and I can see what options are there (for example,
> there seems to be no option to ask FF to follow whatever CDP pointer is
> found in the cert) but I don't know if it was enabled by default when I
> first installed it.
>
> Any help would be appreciated. Thanks,
I will answer separately for OCSP and CRLs.
OCSP:
All versions of FF have the ability to get OCSP URLs from AIA extensions
and (if they are http URLs) attempt to access the server. OCSP checks
are only done on EE certs, when OCSP checking is enabled. OCSP checking
is disabled by default in FF1 and FF2. It is enabled by default in FF3.
In FF1 and FF2, there is no OCSP cache. When OCSP is enabled, an OCSP
check is done every time an EE cert is encountered, when that EE cert
contains an AIA extension for OCSP.
IIRC, in FF1 and FF2, the OCSP client does not know how to deal with
http proxies, and fails when OCSP is enabled but it cannot connect
directly to the OCSP responder.
In FF1, if OCSP is enabled, if the OCSP status check fails for any reason
then the cert is treated as revoked. By "fails", I mean the client is
unable to get a valid response because (e.g.) it cannot reach the server,
or the server's response signature is not valid.
In FF2 (current & recent versions), the user has a preference controlling
whether the cert is considered revoked, or not, when an OCSP check fails.
I believe that pref defaults to NOT consider the cert revoked when the
check fails. However, the OCSP check itself is disabled by default.
In FF3, the OCSP checking is enabled by default. There is a cache,
preventing excessive OCSP (re)checking. The cache is not persistent.
It starts fresh each time the browser is started. The user preference for
behavior upon OCSP check failure exists, as in FF2, and defaults to
treating a cert as NOT revoked on failure. For EV certs only, OCSP
checking will be done on all certs in the chain with AIA OCSP extensions,
not only on EE certs.
In all versions of FF, there is a configuration option to specify an OCSP
signing authority to which all OCSP requests are sent, as provided in RFC 2560.
The OCSP client sends POST requests, not GETs. AFAIK, it does not honor
http redirect responses, and treats them as OCSP failures.
Here is that information in a table:
FF1 FF2 FF3
-------- --------- ---------------
OCSP Enabled by default No No Yes
Works with http proxy No No Yes
client cache No No Yes
certs checked EE EE EE (all for EV)
http access method POST POST POST
cert status upon OCSP failure revoked user pref user pref
CRLs:
In all versions of FF, CRL checking is implemented and is always enabled.
CRL checking is performed only when a CRL is locally present for the
issuing CA. CRL checking is done for all certs except trust anchors.
FF only handles "complete" CRLs, not delta CRLs, not partial CRLs.
It does not support the Issuing Distribution Point CRL extension.
CRLs are not downloaded "on demand" during the course of cert validation.
CRLDP cert extensions are not recognized, and critical CRLDP extensions
cause a cert to be rejected for possessing unknown critical extensions.
This was originally due to a patent issue. That issue has been resolved,
but the work to add support for CRLDPs has not yet been completed.
We hope to add CRLDP-driven CRL fetching by year end.
FF can download a CRL from a user-supplied URL. Once the user has "primed
the pump" by manually entering the URL, FF can download the CRL from that
URL periodically, based on a fixed schedule (every N days) or based on the
nextUpdate date in the CRL. CRL downloading is perhaps the least used
feature in Firefox, and I cannot vouch for its reliability.
Once downloaded, CRLs are stored persistently, on disk, and remain until
they are superseded (replaced).
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
