Kyle Hamilton wrote:
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.
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
