In a lot of countries, giving the government the ability to issue SSL certificates would be a catastrophe in terms of surveillance and censorship.
It doesn't have to be just the state or the UN though. It's not about removing all the other actors on the market.
But if I make a website on Python programming in french, I'm quite ok using the french gov as a CA provider.
I mean, I trust mozilla because it's mozilla. But I wouldn't trust most companies.
Figuring out how best to have browsers check the logs are truly accurate while preserving user privacy (e.g. obviously if you call a log to ask "Did you log this certificate for clown-porn.example ?" it gives them a good idea about your taste in circus-related adult content which you probably don't want them to have) is an ongoing topic of research.
With SCT checks you're in very good shape already today - bad guys would need to compromise several distinct entities to successfully pull this off. It's just not quite "Fire and forget" safe yet.
The SCT is signed by the log, so if you want them to lie you'd need to control enough logs to get enough qualified SCTs. Bad news, for Chrome that means it must include a Google log, which means now you're asking Google to conspire against themselves.
For now you could sidestep this by issuing bogus certificates with back-dated issuance dates. But that will stop working once those dates are too long ago for a certificate to still be valid. I think that happens some point later this year or in 2021 maybe? If you show Chrome (perhaps other browsers but I've read the code in Chrome) a certificate in which the lifespan (between NotBefore and NotAfter) exceeds the maximum permissible lifespan at that issuance date, it treats the certificate as invalid anyway.
https://security.stackexchange.com/questions/31376/can-i-res...
https://www.ietf.org/rfc/rfc2459.txt - section 4.2.1.11, Name Constraints
Given that I don't think you can actually buy that kind of cert, and the term "CA" is accepted to imply "universal CA", you're correct.
These are documented, on a best effort basis, at:
https://wiki.mozilla.org/CA/Additional_Trust_Changes
It is true, however, that no equivalent rules are enforced in most generic TLS clients (e.g. using OpenSSL directly or something like Python).
https://bugzilla.mozilla.org/show_bug.cgi?id=1567114
Not exactly the same as for-website certificates but in the same realm of government certificate issuance.
It’s hard to imagine the old Mozilla enabling DNS over HTTPS by default to Cloudflare, with DoH’s tracking issues: https://labs.ripe.net/Members/bert_hubert/centralised-doh-is...
FTFY
A quick look at a root store turns up
subject=C = CN, O = China Financial Certification Authority, CN = CFCA EV ROOT
subject=C = HK, O = Hongkong Post, CN = Hongkong Post Root CA 1
subject=C = NL, O = Staat der Nederlanden, CN = Staat der Nederlanden EV Root CA [and other roots with the same organization]
subject=C = TW, O = Government Root Certification Authority
I think there are several others, probably especially at the intermediate level.