[cabfpub] Profiling OCSP & CRLs

[Ryan Sleevi]

On Sat, May 13, 2017 at 11:47 AM, Dimitris Zacharopoulos <jimmy at it.auth.gr>
wrote:

> This is a very good description of the situation and the comparison of the
> security concerns between the Certificate issuing system (certificates
> signed by a CA) and the OCSP responder system (responses signed by either
> the CA or a delegated OCSP responder), is fair.
>
> Could we try to focus what should be expected for the off-line Root CAs
> and their delegated OCSP responders? Roots that delegate OCSP responses via
> OCSP responder Certificates and issue responses for 12 months (per BRs
> 4.9.10), should probably have a minimum lifetime of 12 months to match the
> validity of the OCSP response. Currently, the BRs are silent about how an
> OCSP responder should protect its key, so perhaps we could have similar (or
> the same) protection controls for Private Keys associated with OCSP
> Responder Certificates that are delegated from Roots, as the Private keys
> associated with the Root Certificates.
>
> Would it be reasonable to allow for 1-year OCSP responder Certificates if
> the Private Key associated with that responder certificate is
> treaded/protected similarly as the Root Private Keys?
>
> Of course, it would take a while before CAs adapt to such a change,
> especially for pre-generating OCSP responses and serving them to web
> clients through a separate layer.
>

As I mentioned to Tim, it takes more than 'just' protecting the private
key. You need a whole systemic architecture that ensures the flow of
information (and thus the inverse flow of compromise) constantly flows down
from the secure zone to the insecure zone.

Obviously, there's a lot of loopholes in the current text for all sorts of
unquestionably insecure and unadvisable practices (of which some CAs are
engaged in), but it's certainly trying to work through the security goal -
which is that the 'worst case' for a revocation should be bounded by some
O(days) [with the text proposing O(30) as the absolute upper bound], with
leaf certificates bounded by less (currently specified by MSFT as O(7
days), although they tried for shorter)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170513/b51708d7/attachment.html>