[cabfpub] Profiling OCSP & CRLs

[Ryan Sleevi]

On Thu, May 11, 2017 at 2:28 PM, Tim Shirley <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 :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170511/b0413f54/attachment-0003.html>