> the CA would be immediately distrusted by browsers, not as punishment but to deter state actors.
Do you think browsers operate outside of states?
> Compelling by the state to do something that destroys a company is illegal in many jurisdictions
How would it destroy the company? It might affect reputation, but as long as it wasn't the company doing it on its own, they can just claim to be the victim (, which they are). It will only affect the company, if is becomes public knowledge, which the state actor doesn't want anyway. I don't think reputation to not respond to legal warrants is protected by the law. Also for example the USA is famous for installing malware on other countries head of state.
Honestly this is the kind of law enforcement, which is fair in my opinion. It is much more preferable to mandated scanning (EU Chat Control), making the knowledge or selling of math illegal or sabotaging public encryption standards. No general security is undermined. It's just classic breaking in into some system and intercepting. Granted I think states shouldn't do it outside of their jurisdiction, but that is basically intelligence services fighting with each other.
If you're in business of selling X.503 certs trusted by browsers, then not being trusted by browsers kinda limits the marketability of your product.
I don't believe the browsers could be coerced to not distrust such a CA. In every root program I know there's a clause that membership to the program is at browser's pleasure. (Those that have public terms, i.e. not msft, but I'd assume those have similar language.)
Re: they can just do it, well, I think they'd be distrusted the same.
In Symantecgate one of the reasons for distrust was that they signed FPKI bridge, so I think no CA in the future will sign a subca that will sign FPKI certs.
> Also for example the USA is famous for installing malware on other countries head of state.
Yeah, exactly. I think they have more targeted ways that risk less detection and less collateral damage.
Do you thing Google or Apple are going to care? They bowed down to China, I think the state they have their headquarters in has even more leverage. As for Mozilla Firefox on Linux, maybe, but I wouldn't trust this too much either.
> I think they have more targeted ways that risk less detection and less collateral damage.
I think they don't really need to care about this, it was quite clear that no other state is publicly doing anything against this.
This is not practically possible for browsers to do, as it would also cause all of the legitimate certificates signed by that CA to become distrusted and break large swathes of the internet. This was one of the main complaints Moxie Marlinspike had in his 2011 talk on TLS (the contents of which are sadly just as true today as they were then)[1].
In fact, there is fairly credible evidence that the NSA did actually do this already back in 2011 with the DigiNotar hack to steal the contents of Iranian emails[2]. This case was so egregious that DigiNotar did get distrusted by browsers, but other hacks like that of Comodo did not result in their CA certificates being distrusted.
The CAB does apparently block CAs more aggressively than they did a decade ago, but I wonder if they would actually block a big CA like LetsEncrypt if it came out they did something shady or got hacked. It just seems incredibly unlikely they would flip the "turn off >60% of the internet" switch regardless of what LetsEncrypt hypothetically did (for reference, in 2011 Comodo signed only 20-25% of website certificates).
[1]: https://www.youtube.com/watch?v=UawS3_iuHoA [2]: https://en.wikipedia.org/wiki/DigiNotar
That said, I don't think there's a way to stop a nation state from seizing control of a domain they control the TLD name servers for without something like Namecoin where the whole DNS system is redesigned to be self-sovereign.
The system is tamper evident not tamper proof. A nation state adversary can indeed impersonate my web site and obtain a new certificate, but the Web Browser doesn't trust that certificate without seeing Proof it was in the CT logs. So, now the nation state adversary need Proof it was Logged.
Whoever issued them the proof has 24 hours to include that dodgy certificate in their public logs for everyone to see. If they lie and don't actually log it, the proof will be worthless and if shown to a trust root this bad proof will result in distrust of the log's operator. That's likely a six or seven figure investment thrown away, for each time this happens.
On the other hand if they do log it, everybody can see what was issued and when, which is inconvenient if you'd prefer to be subtle like the NSA and to some extent Mossad. If you're happy to advertise that you're the bad guys, like the Russians and North Koreans, you do have the small problem that of course nobody trusts you, so, you can't expect any co-operation from the other actors...
This isn't like a missisuance where you can blame the CA and remove them from the root stores; they'd just be following the normal domain validation processes prescribed in the BRs.
Going to Portland to check whether it's on fire would be a lot of effort - so to some extent I must take it on trust that it's not actually on fire despite Donald Trump's statement - whereas visiting crt.sh to check for the extra certificates somebody claims the US government issued is trivial.
I'm not saying there's no value in being able to detect when you're compromised. I'm just saying it would be better if the compromise wasn't possible to begin with.
When I looked at this ~10 years ago it was overwhelmingly "Fuck it they'll click past the warning" and today that doesn't work† but I don't work in an industry where it's my job to go find out what's happening to valuable targets (in that case military and government systems, typically in Asia or Africa) any more.
† There are more obstacles, more awareness, and better tooling so "doesn't work" is over-stating it but I'd be very surprised if "fuck it" (ie just don't get certificates and impersonate an HTTP-only site instead) was enough today.
What would somewhat help would be CAA record with specified ACME account key. The attackers would then have to alter DNS record, would be harder as you describe. (Or pull the key from VM disk image, which would cross another line).
They can MITM the connection between the host and LE (or any other CA resolver, ACME or non-ACME, doesn't matter). This was demonstrated by the attack against jabber.ru, at the time hosted in OVH. I recommend reading the writeup by the admin (second link from the top in TFA).
This worked, because no-one checked CT.