<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 11, 2017 at 10:02 AM, 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_-1023575002202811555WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Certainly the risk profile is greater for long-lived CRLs and long-lived OCSP responses than it is for long-lived OCSP responder certificates, since CRLs and
 OCSP responses could be replayed to hide a subsequent revocation without compromising the CA’s infrastructure, whereas doing bad things with a long-lived OCSP responder certificate would require the private key of the OCSP responder certificate to be compromised.</span></p></div></div></blockquote><div><br></div><div>Well, no - it doesn't require the private key be compromised. I think that's an important and subtle point here.</div><div><br></div><div>Say I put my key in a FIPS 140-2 Level 3/4 HSM. That's great. I now connect a Web Server do it that talks to the HSM and says "Sign this Response" (e.g. to sign nonces). An attacker doesn't need to compromise the HSM to cause badness - they just need to compromise the Web Server.</div><div><br></div><div>That's the whole point - it requires a systemic design.</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_-1023575002202811555WordSection1"><p class="MsoNormal"><br></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">So the most obvious suggestion to me is that we should have the same key protection requirements (e.g. HSMs) for OCSP responder keys as for online CA keys,
 at least for OCSP responder certificates with lifetimes over a certain threshold.  In that scenario, I don’t see a disadvantage to allowing validity that matched the lifetime of the CA itself, since the responder is no more vulnerable than the CA (assuming
 it’s an online CA.)</span></p></div></div></blockquote><div><br></div><div>See above for a specific scenario (for which I know of CAs having deployed) that substantially increases the risk.</div><div> </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_-1023575002202811555WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I recognize that there’s still a gap in security level for offline CAs though, in that their responders are at the security level of an online CA.  That’s the
 harder problem.  But addressing it with shorter validity requirements pushes a CA towards making their offline roots easier to access, which could cause more security harm than good.  Perhaps we could allow pre-production of a year’s worth of shorter-validity
 OCSP responder certificates as a mitigation against this without requiring the offline CAs to be accessed more frequently?  To get value out of this approach, though, the not-yet-in-service responders would need to be protected differently than the in-service
 one, so we’d need to come up with some rules around that to strike a balance between operational feasibility and security.</span></p></div></div></blockquote><div><br></div><div>I'm pretty staunchly opposed to pre-production, because it just means that the responses, if they leak, can be just as abused as a one-off access to the Web Server above. We'd almost have to keep the pre-generated responses 'offline' and only ensure one of them is 'online' at the time.</div><div><br></div><div>I do agree though that there's a lot of flexibility here with how we guide the design of the system to achieve the overall security goals. PKIX affords substantial knobs and sliders - we just have to find the way to hit the security mark with them in a way that works for everyone :)</div></div></div></div>