[cabfpub] Profiling OCSP & CRLs

[Dimitris Zacharopoulos]

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 <TShirley at trustwave.com 
> <mailto:TShirley at trustwave.com>> 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
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170513/c4c42e81/attachment-0003.html>