Yes. It would add another potential point of failure to the process of publishing content on the Web, if such a scenario came to pass. (Of course, the best-case scenario is that we retain a healthy number of CAs who can act independently, but also maintain compliance indefinitely.)
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.
If there was just one CA then there would be no CABforum and users would have no leverage. This is the situation in DNSSEC. I don't think it's that bad, as one can always run one's own . and use QName minimization, but still, com. and such TLDs would be very powerful intermediate CAs themselves. And yet I still like DNSSEC/DANE as you know, except maybe I'm liking the DNAE+WebPKI combo more. And I don't fear "too few CAs" either because the way I figure it if the TLAs compromise one CA, they can and will compromise all CAs.
Well, it's u/LegionMammal978's novel take, I just riffed on it.
> Personally: I'm for anything that takes leverage away from the CAs.
You can automate trusted third parties all you want, but in the end you'll have trusted third parties one way or another (trust meshes still have third parties), and there. will. be. humans. involved.
