I came here looking for a comment suggesting just that. But surely there is some massive issue with this idea we are overlooking? Otherwise I don't see why it hasn't already been implemented long ago, it seems so obvious as a mitigation.
Also the industry has changed a lot since Let's Encrypt. You could have argued against monopolizing the CA issuance to just a few countries/entities as sovereignty issue, and CAs were indeed exhibiting extreme rent-seeking behavior before Let's Encrypt. With a guaranteed free and accessible alternative in the mix, the weight of the arguments against would change.
You could argue single point of failure, which is fair, so then set up another LE clone which is run in a similar way in another (reasonable) country.
(And there is of course non TLS certs, such as code signing and S/MIME, if that is still a thing. I'm only arguing about the TLS case here.)
That said, starting from the status quo, not sure that's the path of least resistance to get there.
It's also not at all a given that website owners would prefer the national CAs -- as an obvious example, most Rust projects (foo.rs) would probably not trust the Serbian CAs as much as they would LetsEncrypt. Even for website owners that live in the country, it seems possible that Chinese website owners might prefer to use non-Chinese CAs. And again, if the solution is to just special-case one American legal entity then we have just moved back to the original VeriSign-signs-everything model.
The real issue is that the CA model has been obviously broken since at least the days of the Comodo hack -- the trust decision for who can certify the website identity is made by the website owner but really clients are the ones that actually care (it's their data at the end of the day) and they have no input. Moxie had a proposal in 2011 to fix this by letting clients decide the policies for how a certificate should be trusted[1] and I think it is a far more workable solution than the alternatives. If one of the LetsEncrypt intermediates was compromised none of the alternative proposals would have any real hope of providing a workable mitigation.
The major browsers are all US made though, so in the end there is an implicit trust on US vendors, even deeper than the trust on CA.
> It's also not at all a given that website owners would prefer the national CAs
The suggestion is to have a few major ones (LetsEncrypt) be able to sign everything like today but restrict the others. You can still choose to use the US one, just like you basically use CT logs from the US vendor today.
--
In practice, DNSSEC/DANE based solution may be the practical path forward along this line.
.com wouldn't be covered by the proposal made in the post I replied to, because it isn't a ccTLD.
I also disagree with the post author's clarification in a sibling comment, saying that there should be a few major (US) CAs that can sign everything: As I originally understood it, the idea would really be to restrict signing of certs for ccTLD domains to CAs in the country in question, and only to those. There would not be a US CA that can sign certs for French domains and vice versa.
>most Rust projects (foo.rs) would probably not trust the Serbian CAs
Such domains are misuses of ccTLDs as originally envisioned anyway, and AFAIK the relevant standards bodies still see it that way, too.
>it seems possible that Chinese website owners might prefer to use non-Chinese CAs
For what reason? If it's a matter of resistance to government interference, it doesn't help, because ccTLD DNS records are ultimately under the control of that country's government anyway. It might make sense for very small countries in which operating a CA full-time isn't worth it for anyone; perhaps it should be possible for those to be grouped together, sure.
- There are a lot of countries small/technically incompetent enough that this would be contracted out. The contracted-out CA companies would create a larger single point of failure than just one country.
- CAs are used for keys that sign a lot of things other than domains/websites. What about application bundles? Some of the eMudhra intermediates were for that purpose. Who operates those CAs? IMO "OS/app store vendors" is a good answer to this one, but that's not the status quo.
- What counts as a country? There are famously lots of disagreements there. So suddenly Microsoft (or whoever's preloading CA certs onto a lot of computers) has to be in the business of litigating what countries do/don't exist depending on where their devices will be sold. They don't want to do this and so will resist this proposal.
- Business/organization redundancy would be needed. Companies go out of business. Governments get deposed. Datacenters get bombed or hacked. There's no guarantee that CA root or intermediate private keys will be handed over to successor/backup operators when those things happen. Now you need <number of redundant CA operators> X <number of countries> CAs.
- What about non-cc TLDs? If you say "those are less secure and don't need to be country-locked", that's fine, but now you need some additional number of CAs.
- Governments, famously, don't go out of business when they screw up. So it becomes much harder to censure a misbehaving CA.
- When someone (e.g. browser/OS vendors) removes a country-locked CA for misbehavior, this now has to be reviewed as a political act, at which point many more cooks enter the should-we-revoke-this-cert kitchen. We know this from experience with ccTLD domain registrar politics. "We think you revoked Canada's CA because you're in a trade war with them, not because of your stated reason that they did something insecure" or "Don't revoke Canada's CA for using a private key of 124; we need to be nice to them because we're negotiating a trade agreement".
- The net number of CAs needed to operationalize such a system is large: current/legacy ones, plus country-specific ones times redundancy, maybe plus non-cc operators. That's a much bigger list of roots, with a proportionally much bigger risk of revocation/update churn. More churn means more devices running a larger variety of outdated/mismatched configurations, which means much more frequent certificate errors for users, which means an increased tendency to bypass verification or not perform it in the first place.
I agree that the status quo of "dozens of random companies with highly variable competence and affiliation" is bad and should change. I'm not sure that this proposal is better.