<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 15 (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;}
/* 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-size:10.0pt;
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">I wanted to review the Fox It report on DigiNotar again before I respond.
<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"><a href="http://www.rijksoverheid.nl/bestanden/documenten-en-publicaties/rapporten/2012/08/13/black-tulip-update/black-tulip-update.pdf">http://www.rijksoverheid.nl/bestanden/documenten-en-publicaties/rapporten/2012/08/13/black-tulip-update/black-tulip-update.pdf</a>
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">On page 45, the authors of the report stated “It is possible that the CA software that was used was able to produce certificates that have identical certificate
attributes as previously issued certificates. This includes the serial number and the validity dates, … The intruder could have issued certificates that would be seemingly identical to formally issued and trusted ones.”
<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">The attacks seemed to have access to the CA servers in a way that can modify CA server logs and databases. The attackers would also have access to the private
key whenever the netHSM hosting the CA keys was activated which means the attacker could have bypassed the CA software and signed arbitrary certificates.<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">If the forum is not ready to accept changing the OCSP unknown behavior to recommended, then we need to delay the date by a realistic margin (IMO at least 1
year) while we reexamine the issue and gather support from OCSP vendors. I am all for tightening security when possible, but this must be done in a way that all CAs can comply by the deadline.
<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">Kelvin<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"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">
<a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a> [<a href="mailto:public-bounces@cabforum.org">mailto:public-bounces@cabforum.org</a>]
<b>On Behalf Of </b>Erwann ABALEA<br>
<b>Sent:</b> Friday, July 19, 2013 5:31 PM<br>
<b>To:</b> Yngve N. Pettersen<br>
<b>Cc:</b> <a href="mailto:public@cabforum.org">public@cabforum.org</a><br>
<b>Subject:</b> Re: [cabfpub] August 1st Deadline for No "Good" Reponse to Non-Issued Certificate<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">2013/7/20 Yngve N. Pettersen <<a href="mailto:yngve@spec-work.net" target="_blank">yngve@spec-work.net</a>><o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<p class="MsoNormal"><br>
As I believe I said earlier about this: That a specific mitigation can't<br>
fix every possible scenario should not be held against it as a complete<br>
show stopper. No mitigation can stop every conceivable attack vector.<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Right.<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-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<p class="MsoNormal">The duplicate serial number means one of two things: 1) the signing system<br>
allow arbitrary serial numbers, or 2) the signing key itself is<br>
compromised.<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Or 3) the attacker has managed to perform a chosen-prefix collision attack. If the serial number of the legitimately requested certificate isn't predictable, that can't happen (famous last words?). That's why the BR requests CAs to introduce
at least 20 bits of entropy into serial numbers. And that's also why we should push SHA1 out of the game (we're already late).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">In that case, the attacker would be well advised to also generate an OCSP certificate, so the CA's OCSP servers won't hear about the bogus certificates.<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-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<p class="MsoNormal">Case 1: I have no idea how serial numbers are generated in the CA systems,<br>
but I think that they should not be under the control of the requesting<br>
agent, but generated automatically when the certificate is signed. In any<br>
case this require separate mitigation techniques.<o:p></o:p></p>
</blockquote>
<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-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<p class="MsoNormal">Case 2: In that scenario the signing key and certificate must be revoked.<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">So in Case 2 and 3, there's nothing we can do except revoke at a higher level. In Case 1, depending on the CA system, the attacker may also be able to specify more than just the serial number.<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-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<p class="MsoNormal">The timing factor depends upon when the customer gets access to the<br>
certificate. Also, the only OCSP responder that actually needs the<br>
information immediately is the fallback responder.<br>
<br>
Additionally, beside making the responses from the OCSP responder more<br>
thrustworthy, such a mitigation step ensures that the attacker will have<br>
to jump through more hoops, control more of the system, and thus increases<br>
the chance that he will trigger alarms (and as I understand it, during the<br>
DigiNotar incident, the attacker tripped numerous alarms, and the people<br>
at DigiNotar did revoke many certificates, until the attacker disabled the<br>
logging mechanisms that the adminstrators used to track the attackers<br>
activities. As mentioned, the intent of this mitigating step is to stop<br>
that particular attack method, and to bring the meaning of the OCSP<br>
responses more in line with what we expect them to mean ("Good" should not<br>
mean "I know nothing bad about this certificate, in fact, I am not sure I<br>
know whether it exists or not") and a more secure meaning of the responses.<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The intention is nice.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">On one hand, it still leaves some doors open, but as you said in the first paragraph, a *perfect* solution is out of reach.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">On the other, it's clear that a lot of CAs won't be ready in 11 days.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I'm against changing the OCSP behaviour into a simple recommendation, at least for unconstrained CAs.<br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-- <br>
Erwann. <o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>