<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Ryan Sleevi [mailto:sleevi@google.com]
<br>
<b>Sent:</b> Thursday, May 11, 2017 12:18 PM<br>
<b>To:</b> Tim Shirley<br>
<b>Cc:</b> public@cabforum.org<br>
<b>Subject:</b> Re: [cabfpub] Profiling OCSP & CRLs<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Thu, May 11, 2017 at 10:02 AM, Tim Shirley <<a href="mailto:TShirley@trustwave.com" target="_blank">TShirley@trustwave.com</a>> wrote:<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><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><o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Well, no - it doesn't require the private key be compromised. I think that's an important and subtle point here.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">That's the whole point - it requires a systemic design.<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><o:p> </o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><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><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">See above for a specific scenario (for which I know of CAs having deployed) that substantially increases the risk.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><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><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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 :)<o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>