<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 11, 2017 at 2:28 PM, Tim Shirley <span dir="ltr"><<a href="mailto:TShirley@trustwave.com" target="_blank">TShirley@trustwave.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div class="m_-2348860531962428775WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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.</span></p></div></div></blockquote><div><br></div><div>Yup. Exactly this - it's trying to find how to capture this in the BRs in a meaningful way :)</div><div> <span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt"> </span></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_-2348860531962428775WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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.</span></p></div></div></blockquote><div><br></div><div>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 :) <br></div></div></div></div>