> I won't comment on the specifics of this case, but a more nuanced approach regarding security is preferable because it favours transparency.

Certificate Transparency solves a lot of this already. It'd be nice if you could flag your domain as being only acceptable from a CA of your choosing. I don't even think the false positives would be an issue as worst case you have security conscious customers not coming to your site (i.e. you make the business decision).

> If a vendor/CA/whatever knows that they will die if anything comes out, they will bury things like this even deeper.

There's already ways to handle this. Rather than signing everything with your top level cert, you sign a series of intermediate certs and use those to sign the end user keys. The intermediate certificates would be rolled over every N days and creation of new ones should happen offline (i.e. where you keep your master CA cert, the "approved" one).

If you have a system like that in place before shit hits the fan, the damage is isolated to the impacted intermediate certs which could be selectively revoked/blacklisted. If a CQ has not taken those precautions then they've got no recourse when something like this happens.

From a user's perspective, I wouldn't want my browser/OS/app to trust any certificates from these losers. If they can't isolate the damage that's their and their customer's problem. I'm not going to compromise my security for their sake.

> It'd be nice if you could flag your domain as being only acceptable from a CA of your choosing.

HPKP pretty much solves this, and is already being used by a large number of high-value targets.

DNS Certification Authority Authorization (CAA) would also be fairly useful in this regard. It's essentially a DNS record set by a domain owner declaring which CAs are allowed to issue certificates for that domain. These records can then be checked by CAs prior to issuing certificates. It's more or less a defense-in-depth mechanism for other domain validation vulnerabilities, and would've probably prevented these incidents if implemented correctly, though not particularly useful if a CA is compromised completely. I suppose it could also be used by Certificate Transparency Monitors to automatically check if issued certificates are suspicious.

Unfortunately, it's not mandatory yet and so far I believe only a small number of CAs have adopted CAA (Let's Encrypt, DigiCert and possibly some others).

> Rather than signing everything with your top level cert, you sign a series of intermediate certs and use those to sign the end user keys.

This is what CAs already do, including WoSign. I'm not sure if signing end-entity certificates with the root key is even allowed by the Baseline Requirements. Unfortunately, having multiple intermediate certificates to limit the number of affected clients does not really help much if the question is whether a CA should be trusted at all due to their track record, which is what we're talking about here.