What the QWAC? An EV Certificate all over again

A sad thing is that, on its face, this isn’t actually crazy:<p>&gt; 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.<p>&gt; Yep, you read that right. Government mandated Root Certificate Authorities...<p>&gt; 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.<p>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 <i>is</i> 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?<p>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 &#x2F; 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.<p>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 <i>in .eu</i> maps to a given certificate, and browsers should accept that. Except this is pointless — browsers <i>already</i> accept the equivalent of this.<p>IMO it would be more valuable for the EU to do the converse: require that browsers <i>not</i> 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.

What&#x27;s the enforcement mechanism for including the root certs? As far as I know, there is no web browser that is sold for money. That means that if you&#x27;re Apple or Google, you can spin off a company that has no presence in the EU and ship whatever root certificates you want, and it&#x27;s not like you lose out on revenue. You probably dispel a lot of antitrust concerns as well.<p>At the end of the day, what certs you trust is a personal decision. It&#x27;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&#x27;t like Apple&#x27;s set of root certs? Delete the ones you don&#x27;t trust, or use Firefox, or use Chrome.)

So how&#x27;s about the browsers&#x2F;root-programme operators simply stop bundling a root store?<p>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 <i>must</i> provide a root store?<p>I occasionally pick over my root store(s) looking for government-run root-certs for governments I don&#x27;t need to trust. But the names of those root certs aren&#x27;t transparent; you have to research each one before you can safely distrust it.<p>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&#x27;t that common). So I&#x27;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.<p>It would be extra cool if browser manufacturers could restrict government-issued CAs to attesting subdomains of their CC-TLD. It&#x27;s nuts that (e.g.) the Turkish and Hungarian governments can attest any domain they want.

Why don&#x27;t the browsers make the trusted CA root set a choice? Have a radio button selector between the &quot;EU sanctioned&quot;, &quot;Browser safe-default&quot;, and user selectable? Make radio button panel really easy to find and update.

Related ongoing thread:<p><i>Article 45 of eIDAS 2.0 will roll back web security by 12 years</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=38181114">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=38181114</a> - Nov 2023 (77 comments)<p>Also: (others?)<p><i>Joint statement of scientists and NGOs on the EU’s proposed eIDAS reform</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=38126997">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=38126997</a> - Nov 2023 (63 comments)<p><i>Last Chance to fix eIDAS: Secret EU law threatens Internet security</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=38109494">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=38109494</a> - Nov 2023 (299 comments)<p><i>EFF about EU: EIDAS 2.0 Sets a Dangerous Precedent for Web Security</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=33966364">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=33966364</a> - Dec 2022 (44 comments)<p><i>EU legislation eIDAS article 45.2 may force inclusion of insecure QWAC root CAs</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=32093891">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=32093891</a> - July 2022 (36 comments)<p><i>Mozilla and the EFF publish letter about the danger of Article 45.2</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=30549119">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=30549119</a> - March 2022 (13 comments)

It&#x27;s strictly worse because at least a rogue&#x2F;incompetent CA can be distrusted, as the legislation intentionally makes distrusting one of these CAs difficult&#x2F;impossible

I wonder whether site operators could mitigate this by using SPF-like DNS records to say which cert authorities their site uses. It&#x27;s of course possible for a sophisticated attacker to try to interfere with such a workaround but:<p>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.<p>2) Browser vendors, if needed, could verify such DNS records in an EU free connection for most sites.<p>3) Scanners could compare DNS records to results in EU based browser requests and alert the public.<p>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 &amp; app stores.<p>This isn&#x27;t as elegant as the current system of certificate transparency, but meaningfully raises the costs of MITM&#x27;ing connections in an environment where eIDAS is enforced.

Can&#x27;t individuals (on their local systems) just blacklist those root CAs independently of the browsers? I can do that today to trust and distrust any certificate out there. Problem solved right?

What would this mean for let’s encrypt free certificates ? Would their root CA still be recognized in the EU?

Am I the only one who checks the EV cert when logging into the bank?

Browsers could simply make QWACs distinguishable from all other certs. Make sure to show qwac next to the lock. Will the EU say hide the qwac?

The simple solution to this is to promise that any browser instances outside the EU will label these certificates as invalid with very big red scary warnings (maybe mumbling something about risk of state-sponsored attacks). The CAs trying to push those certificates will then quickly lose interest in pushing this regulation...<p>Within the EU, this can also be solved: Pop up a dialog with the certificate, showing &quot;This web site uses a special kind of certificate that &lt;browsername&gt; is by law required to accept. &lt;issuing authority&gt; from &lt;country&gt; claims that this web site has the following identity &lt;claim&gt;. 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. &lt;base64 of the certificate&gt; [ ] do not show again for this certificate and site&quot;.<p>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.

For other confused people, &quot;EV&quot; here is an Extended Validation certificate, and this has nothing to do with Electric Vehicles.<p>The author&#x27;s previous blog post is basically mandatory reading if you want to make any sense of this one:<p><a href="https:&#x2F;&#x2F;scotthelme.co.uk&#x2F;looks-like-a-duck-swims-like-a-duck-qwacs-like-a-duck-probably-an-ev-certifiacate&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;scotthelme.co.uk&#x2F;looks-like-a-duck-swims-like-a-duck...</a>

He leaked excerpts from the text but not the full document. I would really like to read the actual full text document. The fact that the European commission keeps the draft legislation secret is concerning.<p>Is this the typical process for all EU regulation?

The secret text of Article 45:<p>&gt; 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.<p>‘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.<p>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<p>Qualified certificates for website authentication shall not be subject to any mandatory requirements other than the requirements laid down in paragraph 1.<p>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.<p>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<p>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.<p>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.<p>There is also recital text which I did not copy.

Url changed from <a href="https:&#x2F;&#x2F;twitter.com&#x2F;Scott_Helme&#x2F;status&#x2F;1721905520788086836" rel="nofollow noreferrer">https:&#x2F;&#x2F;twitter.com&#x2F;Scott_Helme&#x2F;status&#x2F;1721905520788086836</a>, which points to this.

It&#x27;s pretty funny to me when people defend PKI as something good and nice, especially while criticising EV.<p>As it stands, PKI is EXACTLY good for spying, MITM etc attacks.<p>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.<p>PKI is CIAs wet dream, and it&#x27;s infuriating how people just skip right over that. I actually think it&#x27;s highly likely that certificate pinning was actually killed because it allowed tofu and basically removed all need for outside control.