> At the top of my list of concerns is that browser and client vendors (Root Store Operators) will have a legal obligation to add Government mandated Root Certificate Authorities to their Root Stores, bypassing existing approval mechanisms.
> Yep, you read that right. Government mandated Root Certificate Authorities...
> I could end this blog post right here because anyone reading this will understand the significance of such a statement, and just how much of a catastrophically bad idea that is, but it gets worse.
At the end of the day, (other than the EV-like “additional attested attributes”, which have been tried and were not a success), this makes quite a bit of sense: the EU is the authority as to the mapping from foobar.eu to whatever logically lives there. Norway is the authority mapping foobar.no. The US likewise controls .us, etc. So, if the EU says that foobar.eu maps to some public key, who is Google or Mozilla or Apple to question it?
Of course, all of this is ignoring massive technical issues. DNSSEC really does map domain names to attributes (but not individual names!) in a verifiable manner, and DANE can extend it to HTTPS, but DNSSEC is massively problematic. And the CA / WebPKI system is a baroque mess that is, finally, sort of under control. And the actual leaked text of the proposal does not respect any of what got the CA system under control.
I can imagine a situation in which the EU (through its qualified agents) could attest, cryptographically, which CT or its equivalent, that a domain name in .eu maps to a given certificate, and browsers should accept that. Except this is pointless — browsers already accept the equivalent of this.
IMO it would be more valuable for the EU to do the converse: require that browsers not accept a .eu certificate without attenuation from the EU. Raise the bar, don’t lower it! The EU absolutely has an interest in preventing a US (or Chinese or whatever) entity from falsely certifying an EU site.
EU is varied with all kinds of interests and geopolitical orientations.
For example Hungary. Should we let Hungary certify an EU site?
Hungary is run by now already authorian Orban. Spain has a history of spying their political opponents with Pegasus spyware. Yes, we definitely want to give this guys any authority to tap any of our wire traffic.
https://www.wired.com/story/europe-break-encryption-leaked-d...
I'm saying that I think it really would be reasonable for the EU to require that browser follow a specified mechanism to restrict which certificates are valid for .eu. And it would be reasonable for Hungary to use the same mechanism to restrict .hu. So browsers would only accept a certificate for a .hu domain if it was signed according to standard PKIX and CA/B Forum rules and had whatever standardized attestation was required from .hu.
However the proposed legislation does not, apparently, say this.
Everyone has all of these problems with DNSSEC but no solutions. What's the better alternative? We need a way to verify hostname lookups.
DNSSEC does what it says on the tin. DIYing DNSSEC is a pain in the ass, but in 2023 I think the overlap of folks who self host DNS and aren't capable of setting up DNSSEC is quite small.
I personally think we missed a great opportunity with DANE to decentralize a lot of things, but DNSSEC FUD got in the way.
Appeals to DNSSEC as a decentralization method tend to assume that (a) there are TLDs that are both accessible and reasonably insulated from governmental privacy interference (this is trickier than it looks; .IO, for instance, is squarely within the jurisdiction of the world's most unhinged signals intelligence agency), and that (b) moving established properties to those new TLDs has a reasonable cost, which it virtually never does.
Would be nice if the root servers delegated some TLDs to various experimental projects like blockchain-based name systems and OpenNIC and such (i.e. making domains under those TLDs resolvable for everyone).
They do offer solutions, which typically involve joining their proprietary, centralized, commercial walled gardens.
My understanding is that if DNSSEC were to break nothing would really happen to the public Internet, indicating that it’s not really a load-bearing component.
The security of DV certificates is shaky without DNSSEC.
At the end of the day, what certs you trust is a personal decision. It's not a democracy; there is no need for an entire country to agree on which certificates are trusted and mandate that by law. Pick the ones who you trust, and your choice need not affect my choice. (Most of us delegate to browser vendors, OS vendors, or our employer, of course, but that is a choice. Don't like Apple's set of root certs? Delete the ones you don't trust, or use Firefox, or use Chrome.)
Perhaps the best "big name" distrusted CA would be Symantec: https://blog.mozilla.org/security/2018/03/12/distrust-symant...
Others include WoSign and StartCom.
The problem with eIDAS is that browsers can no longer police these CAs, as they are legally mandated to carry them. There needs to be a mechanism whereby such a CA can be distrusted, doubly so if it is issuing "qualified" certificates (if it cannot get the basics right it should not attest to someone's legal identity).
On the flip side to this there is nothing stopping Europe distributing additional roots that install themselves in browsers. I work in finance and we operate several closed CAs. Our clients install our CAs all the time. It just would not be on by default nor pop up the EV bit.
But that does not stop the digital wallet software (the motivation for this) peering into the certificate itself and making sure it is a qualified certificate.
This isn't entirely true. Let's disregard for a moment the spy agency's wet dream that this law introduces (likely fully intentionally). The more benign intent of this law is to prevent foreign entities from the EU (Mozilla, Google, Apple) from having the final say on whether two kinds of EU organizations (site operators and root CA operators) can successfully reach their clients.
Of course you in your capacity as a consumer don't care whether I trust the same root CAs as I do. But a site operator very much cares whether all of their target audience trusts their site, and by extension the root CA that they are paying, and would like for their government to guarantee this trust.
The theoretical problem that this law is theoretically intended to protect from is browser vendors imposing hostile requirements on certificates which cost EU companies money and/or access to clients. It's a form of protectionism, ultimately.
Of course, the law is clearly being influenced by EU members' security agencies as well, who would love to have the ability to issue fake certificates for any site on the internet. With this new law, they would only need to infiltrate/coerce/fool their local root CA and local auditors, and they'd get free reign over encryption everywhere in the EU at least.
I don't even trust my own country's spy agencies to not spy on me without cause, how could I ever trust, say, Hungary's?
More and more it looks like Linux on the desktop is the only option.
If such a solution would work Microsoft would have done it in it's famous browser monopoly suit
It's like they gave up on trying to actually innovate or grow a tech industry (composed of more than the odd successful euro tech corporation) after years of trying and now they are just banking on their market size to push more and more ridiculous legislation.
I can't wait for that to backfire, or for corporations to not bother anymore (imo the GPDR is the only good thing that came out of this non stop spree of legislation, and that's almost half a decade old now).
At least with China, whatever they do or restrict usually only affects their own home grown tech industry. The funny thing is that if the US gov seriously pushed for something similar to the recent laws (chatcontrol, client side scanning, the weird copyright laws, the "fake news" thing, etc), Europeans would call it fascism or typical American thirdworldism (which is extremely ironic regardless of context).
https://www.europarl.europa.eu/RegData/etudes/STUD/2020/6487...
A company based in Ireland for example, has a really hard time employing someone in Germany, without spinning up a “local branch” in Germany, and thus having to comply with German tax rules as well.
Rules around contractors vary wildly and don’t simplify matters much.
The “solution” is to accept the overheads of a company like Remote or similar who act as an employer of record, but that’s a bodge.
No member state has any real incentive to simplify cross border employment/business rules, so it drags everyone down.
It gets even worse for startups when rules around equity, etc, vary wildly country to country - some countries have extremely hostile tax rules around equity that may never be realized.
What do you think of the Digital Markets and Digital Services Acts?
Agree partly the GDPR though, since it requires disclosure about how collected data is gonna be used.
The most practical way to achieve that is to legislate for a new API in the browser and implement this in the application layer. That will take some time to implement, however eIDAS itself will also take some time to implement.
This would involve the browsers implementing a new eIDAS-only CA store within their browsers. Which is very easy to do as it's new and the API is regulated thus fixed.
The verification flow would work by exchanging attributes (i.e. browser sends crypto-random message to server, server signs it, browser verifies). It adds work to the audit of eIDAS solutions (implementers will f** it up en masse as most of the involved parties are hopelessly bad) but it's better than the alternatives.
Is this the typical process for all EU regulation?
[0] https://www.europarl.europa.eu/legislative-train/spotlight-J...
[1] https://www.europarl.europa.eu/RegData/etudes/ATAG/2023/7392...
[2] https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=COM%3A20...
Laws and regulations should be judged by what they will do. In this case, they will make security worse, witg no adquate compensatory advantage, so it should be rejected.
I think they are not releasing the full text to protect their source in case the text was steganographically marked.
Instead, they could hive-off their root programme into an independent operation. Make it possible for the user to choose which root store they want. Does EIDAS mandate that browsers must provide a root store?
I occasionally pick over my root store(s) looking for government-run root-certs for governments I don't need to trust. But the names of those root certs aren't transparent; you have to research each one before you can safely distrust it.
Most government-run roots are only needed by citizens of that country; e.g. countries that issue government electronic ID that you need for things like voting (which isn't that common). So I'd choose a minimal root store, and then perhaps add back groups of certs, based on what my specific needs were. This could be managed through a slick UI.
It would be extra cool if browser manufacturers could restrict government-issued CAs to attesting subdomains of their CC-TLD. It's nuts that (e.g.) the Turkish and Hungarian governments can attest any domain they want.
The other side of the coin is that you'd then get a community of root-block lists (and root-add lists), like AdBlock lists.
1) The DNS ecosystem is messy with OS, browser and cached records. This makes it very annoying and slow for attackers to target anything but individual users.
2) Browser vendors, if needed, could verify such DNS records in an EU free connection for most sites.
3) Scanners could compare DNS records to results in EU based browser requests and alert the public.
4) Sites with greater concern could additionally post information about which certs their site uses in other public locations like HTML meta tags, public databases, or even centralised locations like search consoles & app stores.
This isn't as elegant as the current system of certificate transparency, but meaningfully raises the costs of MITM'ing connections in an environment where eIDAS is enforced.
The problem (for me at least) is deciding which of the 200-odd roots I want to distrust. If a root has a name that I can't decipher because it's in foreign, that's easy. But most roots have cryptic names, and there's no standard way of finding out who operates a given root, who audits it, or who that root is allowed to issue certs for.
Perhaps there's a market for an open-source root-store editor, that annotates each root with a plain-language description, including stuff like how many certs it has issued, and how many frauds and cock-ups it's been responsible for.
The main problem isn't that it puts any limits on what you can use as a CA but rather that it mandates some of what everyone must trust as one, even if that trust isn't earned (or maintained).
As it stands, PKI is EXACTLY good for spying, MITM etc attacks.
I so wish that a) governments would become their own CAs, this would finally allow us to have actually reliable and secure government level communications and b) tofu would be the standard when communicating with anything on the internet.
PKI is CIAs wet dream, and it's infuriating how people just skip right over that. I actually think it's highly likely that certificate pinning was actually killed because it allowed tofu and basically removed all need for outside control.
Companies, doesn't even have to be the CA themselves, are very easy to coerce into doing the governments bidding, and it doesn't even have to be the entire company, just one person is enough, it's just a change in law that most outside of IT circles support, and it's already law in many, many places.
Like it or not, country level domains are already under the control of their respective country.
And PKI is enabling this coercion, it simply wouldn't be possible if we didn't place trust on these third parties, and place our trust in them all the time, that's a 3 months maximum wait.
As for "bootstrapping" trust, your first connection is always going to be about trust unless you have a side channel to provide you trust (basics of encrypted communications), so trusted CAs are in no way special here, I would much prefer if this trust was provided by say Debian, as it provides the software I'm running. I even much more trust a first connection validity vouched for by an actual government, especially say from Finland than I would trust one vouched for by just some random company.
As for tofu, you do realise attacking it requires capturing and changing ALL traffic, forever, to be effective, as as even though SSH doesn't do it, it's super easy to add forward secrecy to it with a signature update mechanism.
And once you have tofu, you are set. If you can compromise that channel you can also compromise PKI.
PKI is strictly worse than TOFU.
Random company CAs are strictly worse than governments themselves vouching for connections.
PKI is CIAs wet dream.
Article 45 of eIDAS 2.0 will roll back web security by 12 years - https://news.ycombinator.com/item?id=38181114 - Nov 2023 (77 comments)
Also: (others?)
Joint statement of scientists and NGOs on the EU’s proposed eIDAS reform - https://news.ycombinator.com/item?id=38126997 - Nov 2023 (63 comments)
Last Chance to fix eIDAS: Secret EU law threatens Internet security - https://news.ycombinator.com/item?id=38109494 - Nov 2023 (299 comments)
EFF about EU: EIDAS 2.0 Sets a Dangerous Precedent for Web Security - https://news.ycombinator.com/item?id=33966364 - Dec 2022 (44 comments)
EU legislation eIDAS article 45.2 may force inclusion of insecure QWAC root CAs - https://news.ycombinator.com/item?id=32093891 - July 2022 (36 comments)
Mozilla and the EFF publish letter about the danger of Article 45.2 - https://news.ycombinator.com/item?id=30549119 - March 2022 (13 comments)
Within the EU, this can also be solved: Pop up a dialog with the certificate, showing "This web site uses a special kind of certificate that <browsername> is by law required to accept. <issuing authority> from <country> claims that this web site has the following identity <claim>. Such certificates are typically used by (explain whatever the intended use case of these certificates is supposed to be). If you do not expect this web site to use such a special certificate, this may be a government-sponsored attack. The below text will help any technical people investigate. <base64 of the certificate> [ ] do not show again for this certificate and site".
That fulfills both the letter and the spirit of the law while making it very unlikely that these certificates can be used maliciously (and if they were, would make it extremely likely that signed evidence of that would quickly show up). Optionally, allow site operators of major sites to indicate that they will never use such certificates.
The author's previous blog post is basically mandatory reading if you want to make any sense of this one:
https://scotthelme.co.uk/looks-like-a-duck-swims-like-a-duck...
> I have access to the near-final text of the regulation, which is not yet public, but was leaked to me by a confidential source.
‘qualified certificate for website authentication’ means a certificate for website authentication, which is issued by a qualified trust service provider and meets the requirements laid down in Annex IV; Evaluation of compliance with those requirements shall be carried out in accordance with the standards and the specifications referred to in paragraph 3.
Qualified certificates for website authentication issued in accordance with paragraph 1 shall be recognised by web-browsers. Web-browsers shall ensure that the identity data attested in the certificate and additional attested attributes are displayed in a user-friendly manner. Web-browsers shall ensure support and interoperability with qualified certificates for website authentication referred to in paragraph 1
Qualified certificates for website authentication shall not be subject to any mandatory requirements other than the requirements laid down in paragraph 1.
1. Web-browsers shall not take any measures contrary to their obligations set out in Art 45, notably the requirement to recognise Qualified Certificates for Web Authentication, and to display the identity data provided in a user friendly manner.
2. By way of derogation to paragraph 1 and only in case of substantiated concerns related to breaches of security or loss of integrity of an identified certificate or set of certificates, web-browsers may take precautionary measures in relation to that certificate or set of certificates
3. Where measures are taken, web-browsers shall notify their concerns in writing without undue delay, jointly with a description of the measures taken to mitigate those concerns, to the Commission, the competent supervisory authority, the entity to whom the certificate was issued and to the qualified trust service provider that issued that certificate or set of certificates. Upon receipt of such a notification, the competent supervisory authority shall issue an acknowledgement of receipt to the web-browser in question.
4. The competent supervisory authority shall consider the issues raised in the notification in accordance with Article 17(3)(c). When the outcome of that investigation does not result in the withdrawal of the qualified status of the certificate(s), the supervisory authority shall inform the web-browser accordingly and request it to put an end to the precautionary measures referred to in paragraph 2.
There is also recital text which I did not copy.
