[Please follow-up to dev-security-policy -- which is where most things having to do with CA and browser interaction policies are discussed.]
I'm trying to figure out how much of the OCSP slowness and server underpowering is due to the sizes of the keys used, or limitations of the HSMs (and drivers) that these systems are using. I'm not sure what the standard key size for OCSP responders is (and this is something that should likely be asked of the CAB Forum, or at the very least the various CA representatives which hang out around dev-security-policy). Large keys provide more security, at the expense of a near-exponential time increase in having to generate and use them (at least with RSA). The converse is that low-sized keys are much more easily crackable, even if they're quicker to perform the calculations with to respond appropriately and in a timely fashion. OCSP requires that its certificate be issued by the issuer that it serves data for. This means that offline roots can't easily be used to create new OCSP responder certificates, even if it would be useful to use, say, a 512-bit RSA key that's valid for only 30 minutes. (If a CA pregenerated them for an entire year, it would only need to pull out the root key once that year and batch-sign all the OCSP responder certs, at the same time it was used to certify new intermediate CAs.) The other part of the equation is, what if OCSP stapling were properly implemented? Webservers could go out and fetch their OCSP status, good until the expiration of the associated certificate, which (since it would be controlled by the CA) could notify and permit software to enforce its own period of liability for that response. (CRLs are going to be slow, OCSP as an instant responder seems to not be working as well as the designers hoped, so why not use OCSP as -- in addition to everything else -- a means of ensuring that servers know their own certificates' statuses and could trigger an alarm to the technical team if they're found to be revoked for any reason? Why not give OCSP responses the same time-to-show-up policy as CRLs? Why not even, during the time that the current OCSP responder is valid, generate OCSP responses for all certificates in the database with the next-valid key, so that the load can always be kept up with?) (Eddy Nigg, one of the regulars on dev-security-policy, has pointed out that it is stupid to have OCSP responses served by HTTPS. They're already signed by the OCSP certificate, which is usually provided with the response; this suggests that OCSP responses could be pregenerated and then served by something with a kernel HTTP daemon.) -Kyle H On Sat, Oct 10, 2009 at 8:05 AM, Boris Zbarsky <[email protected]> wrote: > On 10/10/09 10:47 AM, Alexander Konovalenko wrote: >> >> Why is security.OCSP.require option set to false by default? > > Because in practice the OCSP servers most CAs run are completely > dysfunctional at worst (e.g. always return HTTP 500) and woefully > underpowered at best. Some of them can handle something on the order of 1-2 > OCSP requests per second, last it was tested (when AMO ended up down because > the CA couldn't handle the OCSP requests for it). So requiring it would > actually mean that sites that use OCSP would just stop working (due to the > browser effectively executing a DDOS on severs not set up to handle it). > >> A man-in-the-middle attacker sitting close to the client can easily >> arrange for the OCSP server to be inaccessible. > > Yes, this is a problem. There's no good solution without CAs updating their > OCSP setup, or Firefox implementing OCSP stapling, or likely both.... > > -Boris > _______________________________________________ > dev-security mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security > _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
