States are themselves extraordinarily large IT enterprises, they generally want control of traffic and its transparency or protection, and they are large enough to get arrangements for that, though usually not this particular arrangement.
Large enterprises in the US generally have the same capability, but not loaded into operating systems by default (that is: Walmart's ability to do this on its own network in no way impacts you, who have never worked on that network).
If you're a large enterprise, then it's trivial to add yourself your own custom CA and save the cost/hassle of needing to deal with outside companies. The tradeoff being you need to manage it yourself vs basically paying this third party company to survive?
That's true, but in the bad-old-days of the antidiluvian WebPKI it was somewhat routine to sell big companies CA=YES certs simply to allow them to do this universally without pushing out updates to all their endpoints. It was a terrible, bad practice, and so far as I know it's completely dead now --- except for Microsoft, I guess.
E.g. identity verification. My state has a "qualified" certificate that can be used to sign contracts and basically everything else you can do in-person. When you can transfer you home with that, there are higher requirements on checking the identity of a person who gets the certificate.
That CA is not used for much else and is basically confined to our state. But it has to be in Windows, otherwise no other software could verify the signatures.
Why would you want to mix identity verification with the WebPKI? This makes no sense at all. Just because a CA is trusted for web verification doesn't mean it's trusted for identity verification, machine enrollment, or any other purpose. And vice-versa: a CA for identity verification is not in any way trusted for web verification.
I think the idea was to use client certs for strong authentication on the government web services, which didn't rally took off, except maybe in Estonia.
You don't really need your CA doing eIDAS in the system root. This scheme works as a closed system where you need eIDAS app to produce the artifact and another eIDAS app to verify it, when both have their own non-system root.
Ukraine for example successfully operates their own eIDAS-like scheme where everything is based on DSTU+GOST algos not supported by any operating systems a major libraries, the certs are signed by the government root and it doesn't leak into web pki.
It doesn't have to be. In Costa Rica the Central Bank has their own CA for the same purpose. We need to download the certificates ourselves. It is inconvenient, but an error by that CA won't propagate to the rest of the world.
Getting your CA into a trust store means that every machine using that trust store will accept your certs. It’s not really necessary for a government or corporation to have a public CA in anyone’s trust store unless they want to issue certificates that everyone trusts. If they just need their own machines to trust their certificates, they can use the management utilities that come with Windows and with AD to distribute an “enterprise root”, which only their machines will trust. This is how most large companies and governments do it.
So when they issue their certificates, you don't get that huge red banner? I belong to a small developing country and even with its tech illiteracy it has a CA. Now, of course, because that CA is not trusted by anyone, all government websites are red.
So that they don't depend on anyone else to have proper TLS for their state sites and for companies operating in their state.
Imagine if you don't have a state CA, and your relationship with the USA goes sour, and the USA prohibits all of their major CAs from doing business with your country, including Let's Encrypt. People in your country still use the internet and you still want to protect them from scammers pretending to be local businesses online. So it's important that you as the state can provide CA services and sign those certificates yourself.
Of course, in this scenario you wouldn't want to be relying on Microsoft to help. But the general principle is that any state who can afford it has a strategic interest in having fully self-sufficient Internet infrastructure, including DNS, CAs, IP allocation etc.
This seems like a matter of signing a certificate signed by an actual CA with your own CA as well. If the relationship sours, you still have your own CA to vouch for it.
That doesn't achieve anything at a country level if trust stores don't include your CA directly. A country can't just push an update to all its citizens' computers to switch CA, it has to plan ahead for such eventualitites.
To be clear, this is bog standard in all mega-corps now. They have a vendor product that provides HTTP Internet proxy, then they perform MitM to decrypt HTTPS traffic and re-sign/encrypt with in-house issued cert. Then, this cert is auto-trusted as part of all base OS installations. To be honest, how else can mega-corps spy on HTTPS traffic without this MitM tactic? I don't know any other way.
Yes, but normally this is done by making your own CA and installing it into your client devices, not by getting it into every device globally by working with Microsoft.
> Yes, but normally this is done by making your own CA and installing it into your client devices, not by getting it into every device globally by working with Microsoft.
Google, Facebook, Microsoft, Apple, Cloudfare, Godaddy, Lets encrypt. They all "work with Microsoft".
You don't need a publicly trusted CA for that. You just run an internal CA and install its root certificate on your employees' machines, just like you install VPN software or whatever else.
Large enterprises in the US generally have the same capability, but not loaded into operating systems by default (that is: Walmart's ability to do this on its own network in no way impacts you, who have never worked on that network).