<div>Incidentally, DigiNotar has declared bankruptcy: <a href="http://www.vasco.com/company/press_room/news_archive/2011/news_vasco_announces_bankruptcy_filing_by_diginotar_bv.aspx">http://www.vasco.com/company/press_room/news_archive/2011/news_vasco_announces_bankruptcy_filing_by_diginotar_bv.aspx</a></div>
<div><br></div><div>LJS</div><br><div class="gmail_quote">On Tue, Sep 20, 2011 at 4:56 AM, Rob Stradling <span dir="ltr"><<a href="mailto:rob.stradling@comodo.com">rob.stradling@comodo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
This year, we've seen 2 types of approach to revocation:<br>
<br>
1. "Normal" revocation (CRLs and OCSP Responses published by the CAs).<br>
2. "Emergency" revocation (Certificate Blacklists published by the Browsers).<br>
<br>
Comodo-gate: All 9 of the mis-issued certificates were promptly marked as<br>
"revoked" in CRLs and in OCSP Responses within a few hours of being issued.<br>
All of the attacker's movements were sufficiently logged, resulting in the CA<br>
being confident that no other certificates were mis-issued to the attacker.  The<br>
compromised application-level account was quickly suspended.  The incident was<br>
disclosed to the major Browser Vendors promptly.<br>
In short: The CA regained control, the CA didn't lose the trust of the Browser<br>
Vendors, and "Normal" revocation should have been enough to ensure that end-<br>
users were not left vulnerable to MITM attacks.<br>
But instead, the Browser Vendors had to resort to "Emergency" revocation<br>
because the "Normal" revocation mechanisms could have been subverted by the<br>
attacker in various different ways.<br>
<br>
DigiNotar-gate: Numerous certificates were mis-issued, not promptly detected<br>
and not promptly marked as "revoked" in CRLs and in OCSP Responses.  The CA<br>
failed to log what happened, failed to disclose the incident for many weeks,<br>
and couldn't be sure that they'd identified every cert that the attacker had<br>
mis-issued.<br>
In short: The CA completely lost control, lost the trust of the Browser<br>
Vendors, and relying on "Normal" revocation would've been like rearranging<br>
deckchairs on the Titanic.  "Emergency" revocation was absolutely necessary.<br>
<br>
So I think we need both types of revocation, but they both need to work better<br>
than they currently do.<br>
"Normal" revocation needs to be improved so that it is sufficient in cases where<br>
the CA regains control.<br>
"Emergency" revocation needs a more coordinated, scalable approach.  (See [1]<br>
for some thoughts from PHB and me).<br>
<br>
On Friday 16 Sep 2011 09:28:56 Peter Gutmann wrote:<br>
<snip><br>
> For example given that an attacker who compromises a CA can add their own<br>
> AIA to the fraudulent certs it mints that point to an attacker-controlled<br>
> responder with another fraudulent cert that "authenticates" any response (or<br>
> simply leave out the AIA, so there's no responder to check), it doesn't<br>
> matter what the rest of the infrastructure does.<br>
<br>
Perhaps this would be classed as a scenario from which the CA cannot regain<br>
control.  And if so, it wouldn't be a problem that "Normal" revocation would<br>
need to consider.<br>
<br>
<snip><br>
> I would really like to see a proper threat model for this.<br>
<br>
I realize I probably haven't achieved that with this post.<br>
<br>
> What are we defending against?<br>
<br>
State-level attackers.  And we should expect them to persist in their efforts.<br>
<br>
<br>
[1] <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=685286" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=685286</a> (the "Proposal for<br>
establishing an emergency response format based on OCSP and DNS/CAA"<br>
attachment)<br>
<font color="#888888"><br>
<br>
Rob Stradling<br>
Senior Research & Development Scientist<br>
COMODO - Creating Trust Online<br>
</font></blockquote></div><br>