No, GP actually has a point. Once you do things like this, you're out. Once you're out, you become a nobody.

Of course, you can reapply to get in (haha, good luck getting a response from Mozilla before a couple of years) but you have to start from scratch all over again. This puts a tangible cost to shenanigans. I highly doubt Verisign would be caught making the mistake these guys did.

Not a good comparison technically, but everyone makes mistakes. And the 2010 event was promulgated by "untrustworthy" employees. The system is risky, and change will have to come sooner or later.

http://www.reuters.com/article/2012/02/02/us-hacking-verisig...

CAs are supposed to be in the business of trust. We are supposed to hold them to the highest standard of machine trust. If they screw up and fix the error in a matter of hours or days... alright. But CAs who charge money for making certificates need to earn our dollars.

Sure, everyone makes mistakes. And if you're in the business of trust, you find ways to uncover and correct those mistakes. Also, you insure against those mistakes, and some of that insurance buys another set of eyes.

Nah, we'd still have plenty of CAs at any given time. After all, it's highly unlikely that all of them will fuck up at the same time. If you buy from a reputable CA, there's at least 90% chance that you won't have any issues during the life of your certificate (1-2 years).

If the requirements for becoming (and remaining) a CA become stricter than they are now, the market will adjust after a while. Peace of mind has always been, and will always be, a very strong selling point. How about this: "We'll sell you three certificates for the price of one! One signed by Comodo, one signed by Verisign, and one signed by GlobalSign! And here's an Apache module that detects when one of your CAs get discredited, and automatically replaces it with a good one!"

Or just create a TLS extension that allow all of the chains to be served as part of the TLS Certificate message.

There's even an SSL extension for the client to mention its list of trusted root CAs in its side of the handshake. It's very rarely used on desktop / on the public Internet because people tend to trust more CAs than would fit in a TCP packet, but it's apparently useful enough in embedded scenarios to standardize.

https://tools.ietf.org/html/rfc6066#section-6

You could imagine a variant for, say, pointing out that you explicitly distrust certain CAs that the server is likely to assume you trust.

Unfortunately, that's not valid per the RFCs (from rfc 5246, TLS 1.2):

"certificate_list

      This is a sequence (chain) of certificates.  The sender's
      certificate MUST come first in the list.  Each following
      certificate MUST directly certify the one preceding it.  Because
      certificate validation requires that root keys be distributed
      independently, the self-signed certificate that specifies the root
      certificate authority MAY be omitted from the chain, under the
      assumption that the remote end must already possess it in order to
      validate it in any case."

I would be super happy if I could send multiple certificates though (provided all my clients magically got tls client library updates to handle it)

Just edited my comment.

> You would have no CA's then.

Would you? We've seen, what, a dozen (at most) CAs do inappropriate things in the last several years? And there are hundreds of CAs? I think things would be fine.

In particular, there are lots of intermediates. My personal website's cert is from Gandi, which uses an intermediate chained off USERtrust. Gandi could arrange to have a second root CA sign their intermediate, so that if USERtrust gets kicked out, browsers can still construct valid chains. And I would gladly pay for such a feature from an intermediate, if the alternative were either my site being at risk of being marked untrusted, or SSL becoming meaningless.

I think the proper number of CAs is a lot closer to zero than it is to the current hundreds.