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.
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.
This was the most anti-colonialist move America had ever made, but you can’t keep tiptoeing around your enemy forever.
As an amateur student of history and a professional watcher of television, I think one possible conclusion I've drawn is that the happy state is tiptoeing around your enemy forever. Or rather, tiptoeing with your enemy. That there is no "and the enemy was defeated and we returned to the Shire and the galaxy is finally at peace." Quietness, even if it's not called peace, is the virtuous state we should endeavour to preserve.
> [...] you can’t keep tiptoeing around your enemy forever.
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.
> 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?
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?
* https://en.wikipedia.org/wiki/.ir
Why would the Iranian government put such a constraint in its own root certificate?
I guess now would be a great time for browsers/OSes to ship a "trust this CA, but only for this TLD/list of domains" feature.
One possible alternative might be to add the ability for user configuration to substitute one certificate for another one (both will need the same public key and subject name, but the substitute will not be self-signed (since you do not have the private key)), and to use the data in the substitute certificate instead of the original. If the name constraints extension is implemented, then it would make this and other things possible. Since the substitute certificate will be considered trusted, it is not necessary for the substitute certificate to have a signature (if it does (e.g. because you got it from somewhere else instead of making it yourself), then the signature can be ignored), nor is it necessary for the substitute certificate to be issued by anyone (this applies even if it is the end certificate being substituted).
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.
This exists in Firefox at least, but I don’t think it’s easily exposed in the UI
It would be simple today to abolish the use of CAs but it just a big cargo biz that makes money on nothing as usual based on peoples incompetence. For 99% of all sites today security would be handled better without CAs. People simply don't understand how it works.
All that was true until fairly recently. Today, you can get certificates for free and there’s more transparency than ever thanks to CT.
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.
> It would be simple today to abolish the use of CAs […]
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.
Exactly, and in some ways, DNS is even more centralized. At least there’s a choice of CAs independent of TLDs.
That's a false concern, because the names the CAs are certifying are still DNS names. If your TLD reasssigns your DNS name out from under you, or even if your TLD starts returning false data on only selected queries, the CAs will be happy to issue a cert to the new holder.
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.
20 years ago would have been a great time for that one.
The whole point with a CA is that you have a neutral third party participant. Kinda broken no matter how you look at it. Especially in this case.
Just like in russia and exactly because of sanctions. Excellent job, dear west.
CAs is the problem. Not who runs them...