**Update 5** The root problem (heh) with the CA model is that in general practice, any CA can issue certs for any domain, so you're vulnerable to the weakest link.  As to who you can trust, I doubt that the list is very long at all, since the stakes are high and security is hard.  I recommend Christopher Soghoian's post on the subject, which clarifies the various approaches that governments around the world have used to get access to private user data - whether by directly demanding it from companies that operate cloud services, via wiretap, or increasingly now via CA coercion or hacks: [slight paranoia: The forces that led to the DigiNotar hack](http://paranoia.dubfire.net/2011/09/forces-that-led-to-diginotar-hack.html).  

Here I provide some specifics, and end with links to some potential fixes.

In 2009, Etisalat (60% owned by the United Arab Emirates government), rolled out an innocuous looking BlackBerry patch that inserted spyware into RIM devices, enabling monitoring of e-mail, so it can hardly be considered trustworthy.  But it is in a lot of trusted CA lists:
 http://arstechnica.com/business/news/2009/07/mobile-carrier-rolls-out-spyware-as-a-3g-update.ars

**Update 1** See also an example of a successful attack, allegedly by an Iranian named [ComodoHacker](http://pastebin.com/u/ComodoHacker), against Comodo: [Rogue SSL certificates ("case comodogate") - F-Secure Weblog](http://www.f-secure.com/weblog/archives/00002128.html).  F-Secure notes that Mozilla includes certificates issued by CAs in China, Israel, Bermuda, South Africa, Estonia, Romania, Slovakia, Spain, Norway, Colombia, France, Taiwan, UK, The Netherlands, Turkey, USA, Hong Kong, Japan, Hungary, Germany and Switzerland. 

Tunisia is another country that runs a widely-trusted CA, and there is also good documentation of the actions of their government to invade privacy: [The Inside Story of How Facebook Responded to Tunisian Hacks - Alexis Madrigal - Technology - The Atlantic](http://www.theatlantic.com/technology/archive/2011/01/the-inside-story-of-how-facebook-responded-to-tunisian-hacks/70044/)

Mozilla notes another questionable practice to watch out for: CAs that allow an RA partner to issue certs directly off the root, rather than via an intermediary: [Comodo Certificate Issue – Follow Up at Mozilla Security Blog](http://blog.mozilla.com/security/2011/03/25/comodo-certificate-issue-follow-up/).  
See also more detail, including speculation about the claim of responsibility by a lone Iranian hacker [Web Browsers and Comodo Disclose A Successful Certificate Authority Attack, Perhaps From Iran | Freedom to Tinker](http://www.freedom-to-tinker.com/blog/sjs/web-browsers-and-comodo-disclose-successful-certificate-authority-attack-perhaps-iran)

**Update 3**: Another successful attack seemingly also by ComodoHacker was against the [DigiNotar](http://en.wikipedia.org/wiki/DigiNotar) CA.  Their website was compromised starting in 2009, but this was not noticed until after DigiNotar had also been used in 2011 by Iranians to sign false certificates for the websites of Google, Yahoo!, Mozilla, WordPress and The Tor Project.  DigiNotar did not reveal its knowledge of the intrusion into its site for over a month.  See more at [DigiNotar Hack Highlights the Critical Failures of our SSL Web Security Model | Freedom to Tinker](https://freedom-to-tinker.com/blog/sjs/diginotar-hack-highlights-critical-failures-our-ssl-web-security-model).

I'd guess that the range of vulnerability of various CAs varies pretty widely, as does their utility.  So I'd suggest refocusing your strategy.  When you can narrow it to specific assets you're trying to protect, just delete all CAs except those necessary for using those assets.  Otherwise, consider eliminating the CAs you judge to be most vulnerable to those who care about your assets, or least popular, just to reduce the attack surface.  But accept the fact that you'll remain vulnerable to sophisticated attacks even against the most popular and careful CAs.


**Update 2**: There is a great post on fixing our dangerous CA infrastructure at Freedom to Tinker: [Building a better CA infrastructure](http://www.freedom-to-tinker.com/blog/dwallach/building-better-ca-infrastructure)

It talks about these innovations:

 * [ImperialViolet - DNSSEC and TLS](http://www.imperialviolet.org/2010/08/16/dnssectls.html)

 * [Network Notary - Perspectives : Improving SSH-style Host Authentication with Multi-path Network Probing](http://www.networknotary.org/)

 * [Google Online Security Blog: Improving SSL certificate security](http://googleonlinesecurity.blogspot.com/2011/04/improving-ssl-certificate-security.html)

**Update 4** One of our IT Security blog posts in August 2011 also covers the case for moving to DNSSEC: 
[A Risk-Based Look at Fixing the Certificate Authority Problem « Stack Exchange Security Blog](http://security.blogoverflow.com/2011/08/31/a-risk-based-look-at-fixing-the-certificate-authority-problem/)

**Update 6** Several Certificate Authorities have been caught violating the rules.  That includes the French cyberdefense agency (ANSSI), and Trustwave, each of which was [linked to spoofing of digital certificates](http://arstechnica.com/security/2013/12/french-agency-caught-minting-ssl-certificates-impersonating-google/).

**Update 7** Yet another set of "misissued certificates", via the  Indian Controller of Certifying Authorities (India CCA) in 2014: [Google Online Security Blog: Maintaining digital certificate security](http://googleonlinesecurity.blogspot.com.es/2014/07/maintaining-digital-certificate-security.html)

See also the question on [Certificate Transparency](http://security.stackexchange.com/q/47230/453) which looks like a helpful approach to discovering bad certificates and policy violations earlier.