To add to this, EU's 2021 eIDAS (the one with mandatory trustlist) was a response to similar lack of availability. Contrary to what most HNers instincively thought it wasn't about interception: EC was annoyed that none of root programs is based in EU, and that causes 100% of trust decisions to be made on the other side of the Big Water. EC felt a need to do something about in, having in regard the fact that TLS certificates are needed for modern business, healthcare, finance etc., they have seen it as economy sovereignity issue.
My point is, lack of options, aka availability, is (or may be perceived as) dangerous on multiple layers of of WebPKI.
No, eIDAS 2.0 was an attempt to address the fact that the EU is not one market in ecommerce, because EU citizens don't like making cross-border orders. The approach to solving this was to attach identity information to sites, ala EV certificates. The idea for this model came from the trust model for digital document signatures in PDFs.
That's orthogonal problem. eIDAS had to solve many problems to create full solution. You're right that we have many TSPs (aka CAs), NABs also. EU have experience running continent-wide PKI for e-signatures that are accepted in other countries. But no root programs in WebPKI, which were essentially unaccountable to EU, but a critical link in the chain in end-to-end solution. There's was no guarantee that browser vendors won't establish capricious requirements for joining root programs (i.e. ones that would be incompatible with EU law and would exclude European TSPs). Therefore the initial draft stated that browsers need to import EU trustlist wholesale and are prohibited from adding their own requirements.
(That of course had to be amended, because some of those additional requirement were actually good ideas like CT, and there should be room for legitimate innovation like shorter certs, and also it's OK for browsers to do suffifcient oversight for TSPs breaking the rules, like the ongoing delrev problem).
1) From an eurocrat pov, why build a browser when you can regulate the existing ones instead? EU core competence is regulating, not building, and they know it.
2) You don't actually need to build a browser to achieve this goal, you just need a root program, and a viable (to some extent) substitute already exists. cf. all "Qualified" stuff in EU lingo. So again why do the work and risk spectacular failure if you don't need to.
3) Building alternative browser for EU commerce that you'd have to use for single market, but likely wouldn't work for webpages from other countries would be a bad user experience. I know what I'm sayig, I use Qubes and I've got different VMs with separate browser instances for banking etc. I'm pretty sure most people wouldn't like to have a similar set up even with working clipboard.
There are things you can't achieve by regulation, e.g. Galileo the GPS replacement, which you can't regulate into existence. Or national clouds: GDPR, DSA, et al. won't magically spawn a fully loaded colo. Those surely need to be built, but another Chromium derivative would serve no purpose.
If you're talking about technical capability, yeah, no contest here.
But if EC can legislate e-signatures into existence, then it follows that they can also legislate browsers into accepting Q certs, can they not?
Mind you, they did exactly that with document signing. They made a piece of paper say three things: 1) e-signatures made by private keys matching Qualified™ Certificates are legally equivalent to written signatures, 2) all authorities are required to accept e-signatures, 3) here's how to get qualified certificates.
Upon reading this enchated scroll, 3) magically spawned and went to live its own way. ID cards issued here to every citizen are smartcards preloaded with private keys for which you can download an X.509 cert good for everydoy use. The hard part was 2), because we needed to equip and retrain every single civil servant, big number of them were older people not happy to change the way they work. But it happened.
So if the hard part is building and the easy part is regulating, and they have prior art already exercised, then why bother competing with Google, on a loss leader, with taxpayer funds. And with non-technical feature, but a regulatory one, which would most likely case the technical aspects like performance and plugin availability to be neglected.
