OCSP responder key/certificate thoughts
Kyle Hamilton
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 <bzba...@mit.edu> 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
> dev-se...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security
>
Eddy Nigg
> 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.
>
Kyle, it's a myth, there are CAs having very responsive OCSP responders
out there....Verisign claims one billion responses per day, I know that
StartCom pushes out Gigabytes of responses per day and Comodo probably a
couple more. It works and OCSP is meant to be fast, not slow. Being a
tool to provide ONLINE and instant information as compared to CRLs with
their lag.
Having said that, CRLs depending on its size probably requires more
resources than an OCSP responder.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Michael Ströder
> Having said that, CRLs depending on its size probably requires more
> resources than an OCSP responder.
That depends very much on the deployment scenario. IMHO there's no general
rule whether CRL or OCSP gives better performance or uses less resources.
Ciao, Michael.
Jean-Marc Desperrier
> 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 think little, but I might be wrong.
If there's really a problem at this level, I wouldn't be shocked if
they'd switch to shorter lived OCSP key that are handled in software.
> 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.
I'd more see a 1024-bit software RSA key that's used only one week, and
can be pregenerated at the start of the year.
But the most important I think is that I don't believe it's the current
practice to provide OCSP response for the levels above the terminal CA.
And terminal CAs are not offline CAs usually.
I'm not sure NSS even does OCSP checkling above this level.
If it's in place, then it's definitively acceptable for those CA to use
pre-signed OCSP response that are valid for one week.
> (Eddy Nigg, one of the regulars on dev-security-policy, has pointed
> out that it is stupid to have OCSP responses served by HTTPS.
It's discouraged by RFC5280 and even forbidden if the https server
certificate is issued by the CA the OCSP server is responding for :
CAs SHOULD NOT include URIs that specify https, ldaps, or similar
schemes in extensions. CAs that include an https URI in one of these
extensions MUST ensure that the server's certificate can be validated
without using the information that is pointed to by the URI.