>> >> In summary, we have to be careful about 'doing something because it just >> seems right'. We need to truly understand the risks, and what we are >> getting for those risks. >> > > Bob, a way to mitigate attacks on OCSP responders (DOS) can be > mitigated to by also supporting CRLs at multiple locations. Also we > considered already multiple different locations for OCSP responders, > I'm not sure if NSS (and other software) would support that.
NSS has supported preloaded CRL, but it treats that separately from OCSP (it always checks the CRL if it's loaded, it never fetches the CRL. OCSP is still interegated with the same semantics as if the CRL didn't exist. As of NSS 3.12, the libpkix code has a much more flexible plan for revocation. It can fetch OCSP, CRL, or both. It can work down the list and stop when it gets an answer (either revoked or not), and it can be configured to require an answer from one of the sources. I believe as of the most recent release of NSS it can also fulfill such requests from it's cache (which is a big win when dealing with intermediates). The CRL fetching on the fly is a relatively recent addition. I don't believe it deals with multiple OCSP servers, but alexi could answer that question. Currently mozilla products only use libpkix when validating EV status. This, of course, only helps if the CRL and OCSP servers are on different hosts with different hostnames, preferably even different domain names. The proxied case isn't solved, but anyone owning a proxy has a much easier DoS than preventing OCSP and CRL fetching;). bob
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
