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.
Thanks,
Dimitris.
On 11/5/2017 10:00 μμ, Ryan Sleevi via Public wrote:
On Thu, May 11, 2017 at 2:28 PM, Tim Shirley <[email protected]
<mailto:[email protected]>> wrote:
Ah yes, good point. Both the private key of the responder cert
AND the system used to generate the OCSP responses need to have
comparable protections/controls to the private key of the
associated online CA AND the system used to generate certificates
from that CA. I believe if you achieve that, then you’ve done all
you can do there, especially since the CA itself could be used to
sign the responses directly if you’ve compromised the system to
that degree.
Yup. Exactly this - it's trying to find how to capture this in the BRs
in a meaningful way :)
That being said, I don’t see any insurmountable issues with
requiring 30 day lifespans for online CA OCSP responders either.
Since the CA is online, renewal of its OCSP responders could be
automated. The challenging one is the offline CA case. I’m not
particularly fond of pre-production either, but didn’t have any
better suggestions. I agree the pre-produced responder
certificates would have to be very carefully protected (ideally
offline) in that scenario to provide any meaningful security
improvement. But perhaps the mechanism of deploying those
responders wouldn’t have to be as much of a production as
accessing the offline CA would be, since a leaked responder would
only be useful if there was also a non-administrative need to
revoke an online CA during (or prior to) the responder’s validity
period. That would enable the rotation to be performed more
frequently than would otherwise be practical. You’re still going
to want a hard limit on how far in advance you could pre-produce
them, but maybe that can be on the order of 6-12 months instead of
having to access your root CA keys every 3 weeks or so to meet a
30 day requirement.
Yup. You've exactly hit on what the goal is - and now trying to figure
out how to word the requirements to capture. I put 30 days as what I
would like to see the _effective security goal_ as, and with the hope
that if we can reasonably agree on that as the desirable goal, we can
figure out how to design/require the system to achieve that, even if
the functional validity is greater than :)
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
