Forcing their customers to install government-affiliated alternative CAs, in turn allowing the government to spy on its citizens more easily via mis-issued certs? Great, that'll show them.
If it doesn't cost the US anything and is strategically in their favor (via weakening an opponent), I really don't see why they couldn't have.
On top of that, it'll make others find alternatives quickly, as has already been happening with e.g. payments and other critical infrastructures. What an incredible waste of soft power built over decades.
How's the support for X.509 "Name Constraints" these days:
* https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1....
Would restricting it to only dot-ir domains be a mitigation?
The main technical way I know of doing this would be by putting TLS public keys in DNS (DANE, RFC 6698), but then you have to make sure that DNS packets are not fiddled with, so you need to bring in DNSSEC.
It would be great to have a widely-recognizable pseudodomain out there where the names were key hashes. It would actually graft really easily into DNSSEC. The zone format doesn't have to change at all; you just declare that if the KSK hash matches the domain label under this specific TLD, you don't need to check upstream of that. Then you add a P2P protocol for getting the actual data, and start slowly pushing that protocol down the resolver tree to incrementally decentralize everything.
What would you suggest as an alternative? TOFU?
I could see that for local applications (e.g. making mDNS/.local and private IP certs TOFU capable by default would be amazing, and maybe even for some explicit hobbyist public TLDs?), but I don’t think I’d love it for my bank or email provider.
I think some servers do not send a copy of the root certificate to the client. In this case, what I described above might already be possible even if that feature has not already been added to existing implementations, as long as it does not require the installed certificate to be self-signed.