That's exactly the internet equivalent of too big to fail banks. And like for banks it is unacceptable. The internet needs its Lehman moment to become resilient again. We should let a Comodo fail.
Symantec, whom one would expect to be one of the more competent CAs out there, cannot do this: https://security.googleblog.com/2015/10/sustaining-digital-c...
But Google did require them to use CT for all new certificates, which I think they are enforcing by assuming Symantec won't lie about the issuance date of new certs.
The other problem is that CAs need to be regionally confined in which TLD CNs they can issue certs for.
Ryan Sleevi makes a good argument here about why that's bad policy for the internet:
https://groups.google.com/d/msg/mozilla.dev.security.policy/...
There are some good arguments in both directions on that thread. I do happen to like the world in which, say, Let's Encrypt is capable of issuing for any TLD. If we don't think WoSign is good enough for signing .com, we probably shouldn't be exposing .cn users to those attacks, either.
I like the discussion in that thread about how to make the scheme reasonably flexible, though. Thanks for the link.
The behavior of consumers in the certificate marketplace is part of the systemic problem: nobody cares very much about their CA, as long as it causes the little padlock to display correctly (and, more importantly, for warnings to not display) in users' browsers. That's it; beyond that it's a race to the bottom on price.
If a few CAs went down in flames and in doing so created a nasty firedrill for all their customers (which, on the scale of firedrills, getting new certs issued really shouldn't be that big of a deal, compared to a zero-day vulnerability in some piece of the server stack, which happens fairly regularly), suddenly there might be an interest in acquiring certificates from somewhere other than the cheapest-possible source.
How? I've got no way to judge the security / responsibility of any CA. The amount of money that they charge may have no relation to their behaviour. I don't think anyone has claimed that the CAs who issued wrong certs were charging less than their competitors. You can't blame the CA customers for this.
How CAs respond to issues on these mailing lists and in bugzilla is also pretty telling.
In this particular case, there's been concerns raised for several days. An extra vigilant web site operator who sees these discussions might perhaps come to the conclusion that it would be wise to evaluate switching CAs today, perhaps.
We're all doomed then! Asides from LetsEncrypt, most CA web pages are full of marketing fluff :)
I've just been reading through the mailing list discussion, and from that I agree with you completely, WoSign looks pretty incompetent in their responses. If I had a WoSign certificate, I'd definitely be looking around to get an alternative now. However, that's a bit late for 'people power' to force CAs to act better.
Of course, the CA would then be incentivized to publish their procedures and show how they intend to fix the breach, which shouldn't have happened in the first place, to regain customer's trust. Or go bankrupt. Let me tell you they wouldn't let their employees do mistakes.
Customers who stay, in the situation that it is discovered that Symantec issues another rogue cert, which causes Mozilla to completely revoke Symantec, can later sue Symantec for harming their business by not applying their public procedures. And here's how the economy gets rid of bad actors. The rule is much tougher for cloud machine providers (EC2 and DO): Should they lose one customers' data, everyone would leave them and go bankrupt, that's why they don't.
In parallel, losing a CA doesn't harm the customers very much, even for amazon.com. They can buy a new certificate in a matter of hours. bzbarsky even says it's commonplace to have the certificates signed by 2 CAs.
There would be a slew of reviews of CAs, judging their perceived odds of vanishing in a puff of paperwork, if there was an interest in issuer stability. CAs themselves could probably offer value-added features like guarantees backed by outside parties (i.e. an insurance product) that would pay costs associated with certificate reissuance in the event of malfeasance or incompetence on the part of the CA.
The market would provide, but there has to be demand. Right now there's no demand, because the consequences of getting a cert from a crap issuer has, historically, been approximately zero.
Why? CAs just operate as a tax on sites. Having a certificate doesn't buy a site much; it's typically more for the _users'_ convenience, since they are the ones relying on the CA.
Really, users should pay CAs (probably indirectly), and CAs should issue certs for free. But I doubt that'll ever happen.
One is to reengineer the CA trust system to delegate limited authority to CAs (e.g. there is no good reason for a CA in the US to be able to sign certificates with Chinese TLD CNs, and vice versa).
The second is to build out the Certificate Transparency project to the point where the revocation of trust due to a mis-issued certificate is immediate, widespread, and automatic.
I'd love to hear more about this. How would it work?
Lets Encrypt gets a lot of flack because their certs need to renew every three months. I can't imagine why bad actors wouldn't immediately try to swamp any system of revocation with requests.
Any certificate issued for e.g. github.com by any other CA immediately become evidence of malicious conduct attributable directly to that CA, and grounds for automated revocation of trust.
I'm not sure what the lifetime of Let's Encrypt certs has to do with this. I'm also not certain how the bad actors would exploit this process, can you explain?
[1]: https://docs.google.com/document/d/1VDtHiKa5c96ohP_p-V1k6u83...
As these things develop and become increasingly security-critical parts of the protocol, it would be nice if programs like libcurl and other HTTP client libraries gained support for them.
Sure there is. If you have a .cn domain but don't trust Chinese companies not to MITM your site, you can get a cert from a foreign CA and then pin it using the HSTS preload list.
That way, even if the registry hijacks the domain and sends people to a server with a valid (but fraudulent) cert, you're still protected by the pin.
Because then you're stuck using that country's CAs, and so you can't pin the root or intermediate certs without giving them the keys. You could pin your cert, but that has other disadvantages.
Note that this is also how a new CA is bootstrapped: initially the certs it issues are cross-signed by some existing CA so they work even in UAs that don't have the new CA in their trust root.
The obvious drawback is that now sites need certs signed by two CAs, and getting them to use even one CA is hard enough...
In the CA world, I would assume this would require a standard protocol across CA to request, renew and transfer certificates from CA providers automatically. A sort of commercial version of the ACME protocol. But that requires lots of infrastructure change not just on the CA side, all servers would have to be updated.
This is long overdue anyway. It is currently way too complex to request, install and keep updated a certificate. And there isn't enough competition in this market.
Getting a certificate is an hour's work tops if you are doing the csr dance manually. If you use ACME and letsencrypt it's done in seconds.
EV certificates are more work but if this matters to you then perhaps you should source multiple certificates to begin with, or act quickly when a CA is dropped (I'm sure browser vendors will give at least a few days notice)
Edit: Maybe I misunderstood you. If you just meant that software in general should offer requesting certificates from any provider, then sure, why not just use ACME. CertBot appears to be designed with multiple providers in mind. But this doesn't really have much to do specificially with the case of CAs being dropped from the root. (At first I got the impression you wanted other CAs to "bail out" certificates from the revoked CA)
I suppose you could downgrade on automatic transfer. I've heard people question the value of EV certs, and certainly a working DV cert is better than a revoked EV cert. Or you could insist every EV cert applicant verify their identity with two different CAs.