I'd rather have a system where the same criteria apply to all CAs independent of their jurisdiction, coupled with mechanisms that guarantee transparency (like Certificate Transparency) and stuff like key pinning.
I only recently found out that anyone that can reliably man in the middle your server can get a valid HTTPS cert from CA's like Let's Encrypt. That includes cloud providers, backbone providers and possibly the local government where the server is located. [edit: It also includes anyone that can temporarily modify or spoof your DNS records.]
The CA/Browser Forum has endorsed a variety of ways of proving control over a domain; for each of them, if some CA uses it and you can spoof it, you might be able to get that CA to misissue a cert for that domain.
The desire to somehow tighten this up is in tension with the desire to make HTTPS ubiquitous, and an underlying problem is that we're on the Internet where there is no central identity mechanism or source of proof of identity assertions -- except perhaps the DNS root and all of its associated registration and delegation mechanisms.
Maybe someday we could slightly clean up DV by making the proof of domain control go through DNS domain registries, since they're the underlying source of authority or ground truth in the DNS system right now. We could imagine a protocol where a CA has to ask the registry whether a particular certificate request is really from an entity that the domain registrant has approved, and both the CA and registry could publicly log the question and answer. (Perhaps we'll also have certs for other kinds of naming systems as well.)
In the meantime, you can make a CAA record, use HPKP, like pfg said, and check the Certificate Transparency logs. None of those are perfect, but they're a lot better than what we had with DV five years ago.
Or maybe registries could directly act as CAs for their own TLDs (and no others). It would be an interesting discussion about how this would be better or worse than what we have now.
I imagine a lot of registries wouldn't want to pay for the infrastructure to do this, but maybe it should be regarded as a basic part of their role. Right now it would be very annoying because you could no longer get a cert for multiple names under different TLDs, at least if they were managed by different registries (so you couldn't get a single cert covering example.io, example.cc, and example.net, even if you controlled all three names). Maybe if SNI becomes more ubiquitous this limitation will seem less annoying in the future.
That'd at least mean an attacker would need to be MITMing the connection close to your server/loadbalancer instead of near to the CA?
Wouldn't help if someone was doing a Quantum Insert style attack from within your hosting infrastructure. (I wonder if there's pre-build AMIs to let you quickly spin up open source implementations of Qantum Insert on AWS already?)
Most CAs that operate today are located in countries where mechanisms exist that could very well be used to force a CA to hand over private keys and/or sign certificates, not to mention that some intelligence agencies (or other actors) might use not-so-legal means to achieve the same thing. So why bother trying to enforce some kind of "NSLs (&co.) are bad unless you're one of The Good Guys" rule rather than embracing a mechanism that guarantees that CAs will be caught when they engage in such behaviour (willingly or not)?
