The problem isn't merely the fact that the EU wants some control over the process, it's the fact that the EU wants to revive a bunch of dead ideas and bad CAs in the process of doing so. The article specifically cites a CA that was banned from root trust stores which the EU wants to forcibly
un-ban, which is very bad.
Yes - strictly speaking, those bad CAs can still issue "cryptographically secure" certs. However, the layman does not have a clue what "cryptographic security" means. They just hear "~~b̷̧͚́͝ȧ̷̠̜̦̉k̵̯̘̠͊̂e̴̞̓̃m̵̹͒̂͠o̵͎̣̎̓n̴͔̤̖̊̑o̴̙̰̼̍c̶͖̅͊h̶͔͛̇̓i̸͚̎n̶̮̬̊̒c̴̮̈̌ḣ̸̹i̵̤̊̈́n̴̹̮̾̃̈́~~ security", parse out the bits of English they do understand, and treat the rest as a linguistic intensifier, which is highly misleading.
In fact, "cryptographic" in this context specifically ignores the authentication of the key. It just means that it's computationally infeasible[0] to decrypt the message if you only have the ciphertext. However, in order to get this security, you need to make sure only the intended recipient has the key. This not only means that the recipient needs to keep their key safe, but that you need to make sure that you're using the intended recipient's key. Otherwise, an attacker could just hand you their key instead of the recipients, and then decrypt your messages and do whatever they want with them.
In other words, secure key authentication and exchange is a necessary precondition for cryptographic concealment.
In some simple cryptosystems, we don't talk about this, mostly because we imagine the recipient and sender exchanging keys in such a way that the system doesn't need to care about it. Perhaps they exchanged paper keys in person in the middle of a potato field in Idaho. However, this is highly restrictive; imagine having to drive to every tech start-up's HQ to copy some QR codes with their public keys on it before you could visit a new website. What we would rather have is a way to take one securely-exchanged key we already have, and use it to securely exchange more keys over the Internet.
That's what a CA ultimately is - an entity we already have keys for, that is capable of making sure our recipients are who they say they are. So if I go to news.ycombinator.com, the server I connect to will send me a message from that CA saying that they checked the server and validated that it's run by the person who owns news.ycombinator.com.
Except now that makes the CA the weakest link in the system. A CA that is malicious can totally strip any and all of the protections that HTTPS is supposed to provide. So browser vendors are really, really picky as to what CAs they put in their trust stores. CAs that habitually make mistakes or lie out of their asses get removed because they are not trust-worthy. Any legal proposal that would make it easier or even possible for them to reverse such a decision needs to be treated like cancer.
Yes, I know that browser vendors hold a lot of power in this equation - but there is little evidence that the measures they impose upon CAs are excessive or pretextual. Furthermore, the proposed replacement is making mistakes that the browser vendors aren't, so it's a strict security downgrade for no added freedom[1].
[0] trying every possible key requires more compute time than exists in the current universe
[1] CAs are sideloadable on every device ever. Yes, even iOS. However, the only use for this is for...
- Securing local web servers without an FQDN
- Using enterprise security/spyware/filtering products that need to strip HTTPS in order to work
I know of no case in which a CA has gotten into the business by telling people to install their alternative certificate. There are some edge cases in which very large CAs - specifically Let's Encrypt - have transitioned from having another root cross-sign them to becoming a root CA themselves. However, that only affected really old devices, and you could at least theoretically install the ISRG Root X1 cert on that device to work around this.
https://letsencrypt.org/docs/dst-root-ca-x3-expiration-septe...