<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">2013/7/20 Yngve N. Pettersen <span dir="ltr"><<a href="mailto:yngve@spec-work.net" target="_blank">yngve@spec-work.net</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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.<br></blockquote><div><br></div><div>Right.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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.<br></blockquote><div><br></div><div>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).</div>
<div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Case 2: In that scenario the signing key and certificate must be revoked.<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br></blockquote><div><br></div><div>The intention is nice.</div><div>On one hand, it still leaves some doors open, but as you said in the first paragraph, a *perfect* solution is out of reach.</div>
<div>On the other, it's clear that a lot of CAs won't be ready in 11 days.</div><div><br></div><div>I'm against changing the OCSP behaviour into a simple recommendation, at least for unconstrained CAs.<br clear="all">
<div><br></div>-- <br>Erwann.

</div></div></div></div>