Other errors I noticed in the analysis:
- DigiNotar hadn’t detected the breach and production of false certificates, so they couldn’t immediately report the incident. They failed to cooperate (and started by denying the incident) once the fraud was detected by Google and their CA pinning (which is similar to DANE), but “no immediate incident reporting” is not their first failure. If Google hadn’t implemented this CA pinning feature in their Chrome browser for their own domains, the Iranian people would still be eavesdropped by now.
- “fundamental weaknesses in the design of HTTPS”. What are they talking about? TLS is used to secure other protocols (SMTP, LDAP, IMAP, ...). TLS was at first based on X.509 certificates, but can be used with other authentication schemes (KRB5 or PSK for example). HTTPS suffered some months ago of renegotiation problems, some weeks ago of IV reuse (it also applied to other protocols, and directly attacks TLS1.0, but BEAST uses the browser as a vector, so I consider it an HTTPS attack). The critics finally goes to the fact that the browsers all have a large trust store, but hey! the same people criticized the fact that DNSSEC was finally based on only one actor, VeriSign. Cryptographic algorithm agility is a good thing, CA agility also. Browser vendors ask for independent and regular audits, read the CP and CPS, ask the CA to follow their own policy. CAs all must do the same. The failure of DigiNotar is only DigiNotar’s fault, not browser vendors’ or other CAs’ fault.
- the distrust (not only removal, read NSS source code) of DigiNotar is not based on ignorance of all the fraudulent certificates by DigiNotar, but on the fact that this CA completely failed to act as trusted actor: lack of security procedures, bad practices, denial of cooperation during the resolve phase. If you are judged because you miserably failed, don’t lie or you won’t be able to negotiate your sentence.
- Comodo was also attacked (it is assumed the attacker was the same), but not directly. Some RA (Registration Authority) were penetrated, these RA are not covered by audits and/or policies (it’s being changed). The CA has a list of all fraudulent certificates and can revoke them. Comodo actively participated with browser vendors. I don’t work for Comodo but for a competitor, but I admit they had a good reaction.
- “weak revocation check”. That’s untrue. Major browsers check for revocation status, using OCSP if a responder URL is declared, and eventually falling back to CRL download. For non-EV certificates, that’s right, the checks are insufficient. But EV validation path is more strict, and a certificate declared revoked will raise an alert.
- “usability issues”. Some progress have been done in recent browsers to alert the user that something failed (see Firefox for example). The user can control which CAs can be trusted, so users with high security requirements can choose to distrust any CA they want. It’s non obvious, for sure, but it can’t be easy and difficult at the same time. Letting an illiterate user easily trust a bad CA while displaying more invasive security warnings is not coherent.
I don’t think Convergence is a good solution. In fact, it’s actually worse than DANE. And I don’t like DANE neither ;)
I think something good can emerge from the CABForum, where browser vendors (and their user base) and CA (and companies) are represented. EV certificates was a step in the right direction, it works. DANE and Convergence can only offer the same level of trust as DV certificates, which were deployed by cost-killer CAs, when other CAs offered OV certificates.
