I agree with Dimitris’ disappointment with Mozilla for setting up such a misleading website – this is harmful to Mozilla’s reputation.
Mozilla, on behalf of the browsers, is lobbying against legislation now before the EU Parliament intended to amend various parts of the 2014 eIDAS statute (“electronic IDentification, Authentication and trust Services” in the European Union). The legislation covers many subjects, but Mozilla’s attacks are on the updates to Article 45 covering Qualified Web Authentication Certificates (QWACs). QWACs are similar to Extended Validation (EV) Certificates (they strongly identify the owner of a website through the TLS encryption certificate), but with additional security safeguards for consumers. QWACs are only issued by Qualified Trust Service Providers (QTSPs), which are Certification Authorities (CAs) established in the EU who must follow ALL of the SAME CA/Browser Forum requirements as every other CA in the world (including those browsers who are also CAs, such as Google). QTSPs must follow additional ETSI technical standards not applicable to other CAs, and are continuously monitored by their ETSI auditors. Finally, QTSPs and their trust services must also be approved by a national supervisory body before they can be listed on the EU Trust List and offer services like QWACs to the EU public. https://esignature.ec.europa.eu/efda/tl-browser/#/screen/home Why does the EU want these changes to existing eIDAS Article 45? The EU is strongly committed to its own “digital sovereignty” to protect EU consumers, and is no longer willing to allow US big tech companies to dictate all the rules of the internet based their own subjective judgment and commercial interests. The EU has asked browsers (including Mozilla) to work with it on these issues since 2015, but the browsers have never been willing to cooperate. The 2022 changes to eIDAS Article 45 is the result of this lack of browser cooperation over the years, and the grossly misleading website set up Mozilla is just a part of a massive lobbying effort by the browsers to turn the EU Parliament against the proposals of its own EU Commission. Misleading, and very disappointing. The eIDAS 2 Article 45 legislation includes two main changes to existing EU law on QWACs: (1) The EU wants browsers who distribute their software in the EU to bring back a common identity UI (like the one they showed to users for QWAC and EV certificates until 2019, when they arbitrarily removed the identity UI) so consumers can know “who they are dealing with” when they provide their personal data (password, credit card number) to a website. EU consumers actually already have a “right to know” who they are dealing with under GDPR and two other EU laws before they provide websites with their personal data. The browsers are not respecting this legal right in their current UIs. (2) In addition, the EU wants to establish its own “digital sovereignty” for EU citizens through its own EU Trust List for trust service providers – and it does not want US big tech browsers to have the unilateral subjective right to distrust a QTSP based on the browser’s own whim, without applying public and objective standards and a without granting any right to appeal and obtain review of a browser decision by a trusted technical body such as ENISA. For this reason, revised Article 45 requires browsers who distribute their software in the EU to “recognize” QWACs – that’s all. The browsers are strongly lobbying against these two important EU Article 45 goals, and the Mozilla website is part of this disinformation campaign as described by Dimitris. Finally, it’s important for the Mozilla community to read the ACTUAL language of eIDAS 2 Article 45 on QWACs that is the subject of Mozilla’s anti-QWAC website. The ACTUAL language is shown below – compare this language to the embarassing disinformation on the Mozilla website: ***** eIDAS 2 - Recital (32): Website authentication services provide users with assurance that there is a genuine and legitimate entity standing behind the website. Those services contribute to the building of trust and confidence in conducting business online, as users will have confidence in a website that has been authenticated. The use of website authentication services by websites is voluntary. However, in order for website authentication to become a means to increasing trust, providing a better experience for the user and furthering growth in the internal market, this Regulation lays down minimal security and liability obligations for the providers of website authentication services and their services. To that end, web-browsers should ensure support and interoperability with Qualified certificates for website authentication [QWACs] pursuant to Regulation (EU) No 910/2014. They should recognise and display Qualified certificates for website authentication to provide a high level of assurance, allowing website owners to assert their identity as owners of a website and users to identify the website owners with a high degree of certainty. To further promote their usage, public authorities in Member States should consider incorporating Qualified certificates for website authentication in their websites. *** eIDAS 2 - Article 45 - Requirements for qualified certificates for website authentication *** [1. Specifies what QWACs are – no changes from current law.] 2. Qualified certificates for website authentication [QWACs] *** shall be recognised by web-browsers. For those purposes web-browsers shall ensure that the identity data *** is displayed in a user friendly manner. Web-browsers shall ensure support and interoperability with [QWACs] ***. 3. Within 12 months of the entering into force of this Regulation, the Commission shall, by means of implementing acts, provide the specifications and reference numbers of standards for [QWACs]. *** On Friday, July 15, 2022 at 10:36:20 AM UTC-7 [email protected] wrote: > Moudrick, > > I don't understand how this is related to the discussion in this thread. > If you have a specific concern about an existing TSP, the eIDAS framework > allows you to file official complaints to the corresponding SB. If this > process fails, you will have a good case to present with specific > evidence/facts. > > Regarding the Mozilla article, I am disappointed about the fact that it > was assigned to a "strategies" company and is loaded with inaccurate and > "noisy" statements without any concrete evidence to support the statements > made. > > "This campaign has been developed by Mozilla to help drive industry > reform. Learn more about Security Risk Ahead and our business at > www.mozilla.com. This website is operated by Hill+Knowlton Strategies | > July 2022" > I was hoping for a more objective and balanced approach. The eIDAS > framework is not completely "trash". Can things be improved? Of course they > can. But we need specific proposals with proper justification to improve > things for the benefit of all Relying Parties. I didn't go through the > details of the article because it is already extremely biased with > statements like: > > - WHY ARE QWACs A PROBLEM? > - Why QWACs are not secure > - Discover how QWACs can put you at risk > - How QWACs harm online rights > - *How QWACs and eIDAS can harm individual cyber security* > - *Online threats in the EU are on the rise* > - *How QWACs create risk* > - *Help browsers protect you from harm* > - *How eIDAS legislation could put fundamental rights at risk* > - *eIDAS will open users up to attacks* > - *Help browsers protect internet users* > > which deterred me from reading any further. It almost feels like it tries > to "brainwash" readers with statements like that. > > I'm also surprised that whoever took money to build this website on behalf > of Mozilla, completely ignored the Mozilla principles and manifesto: > > - "We are committed to an internet that elevates critical thinking, > reasoned argument, shared knowledge, and verifiable facts." > - "We are committed to an internet that catalyzes collaboration among > diverse communities working together for the common good." > - and in some ways, it is also related to "Commercial involvement in > the development of the internet brings many benefits; a balance between > commercial profit and public benefit is critical." > > I hardly see any "balance" being promoted in this article. > > > Dimitris. > > > > On 15/7/2022 1:59 μ.μ., 'Moudrick M. Dadashov' via > [email protected] wrote: > > Good day, Phillip > > If we notice "US-centric" perspective, we should also notice EU-centric > perspective that relies on unelected, unaccountable public sector bodies > doing "supervisory body business" under patronage of pan-European > corporations. > > To be more specific let me remind you millions of surrogate QSCDs and > QESCs in circulation today - the product of corruption network led by the > Swedish telco-banking cartel - the semi-state Telia Company AB (aka > corruption academy) and two well known laundromats - Swedbank and SEB. > > BTW, the ORGANIZED GROUP has its own embassy in Brussels. > > I wish someone from mr. Norbert Sagstetter’s team could join the > discussion. > > Thanks, > M.D. > > > Sent from my Galaxy > > > -------- Original message -------- > From: Phillip Hallam-Baker <[email protected]> > Date: 7/15/22 13:32 (GMT+02:00) > To: "Enrico E." <[email protected]> > Cc: [email protected], "[email protected]" <[email protected]> > Subject: Re: Mozilla Campaign: securityriskahead.eu > > I don't necessarily disagree with the argument being made there. But I > think it would be best if all three parties (Government, Browser Providers, > CAs) moved past the original framing of 'Should Google or Government decide > who you trust' because it is the wrong question: > > The user should decide who to trust. > > As we have seen, Google has unilaterally exercised its ability to drop > roots out of its store effectively forcing CAs to shut down or be > transferred to other operators. Mozilla might think it has a dog in this > fight but it is not really Mozilla that is the target of the very real > national security concerns that have been raised. > > Looking at those concerns from a US-centric silicon valley libertarian > perspective is probably not helpful when the decision makers here are > Europeans and their elected representatives. > > > > On Fri, Jul 15, 2022 at 8:29 AM Enrico E. <[email protected]> wrote: > >> Dear all, >> >> I would like to bring in a different view on the whole topic. In April >> this year this article https://rdcu.be/cJQpU on Qualified Certificates >> for Website Authentication (QWAC) was published in the journal Datenschutz >> und Datensicherheit (data protection and data security) . We explained why >> QWACs can help to protect the user in European Union, why the QWAC is an >> important feature of the security of the digital infrastructure in the EU, >> and why the new proposal of the commission is a step in the right >> direction. In the article, there are preliminary suggestions for how to >> implement the new article 45 proposal. >> >> Thanks, >> >> Enrico >> >> [email protected] schrieb am Donnerstag, 14. Juli 2022 um 14:30:17 UTC+2: >> >>> As with the Google response, you are taking a very US-centric approach >>> to lobbying that is only going to reduce the chance of influencing the >>> outcome. EU politics are not the same as US politics. >>> >>> Case in point, the site isn't translated into German, French or Spanish. >>> There aren't very many English speakers left in the EU after Brexit. >>> >>> Unlike US politicians who are mostly self important numbskulls, most >>> MEPs are very serious people. These are (mostly) the politicians who have >>> complete command of their briefs. They are not going to be convinced by the >>> argument that QWACs represent a threat to the security of the Internet >>> while LetsEncrypt's free certificates with no validation whatsoever are >>> just peachy because that is a really bad argument to try to make. >>> >>> The EU concern here is that Google is setting itself up to be the >>> monopoly provider of trust in the Web and that eliminating EV certs is a >>> part of that strategy. If you want to influence the outcome of this issue, >>> you need to provide them with an alternative approach to achieving that >>> end. I will explain how to do that at the end, first I have to explain my >>> point of view. >>> >>> >>> The heart of VeriSign Class 3 and the Extended Validation requirements >>> was establishing the accountability of the subject. It was never about >>> identity. The notion was that if someone is going to be engaged in criminal >>> activity, they would only do so as long as it was profitable. Creating one >>> fake corporate identity is simple, creating disposable identities is >>> deliberately hard. Knowing that you are doing business with a company >>> registered in the US has different risks to one registered in the UK or in >>> Germany and the risks of dealing with a company registered in Nigeria or >>> Russia are very different again. >>> >>> VeriSign Class 3 and EV both outperformed my expectations. They weren't >>> perfect but security is the management of risk, not risk elimination. >>> Neither Firefox nor Chrome is free from sin either and writing code without >>> security vulnerabilities is a task that is entirely within the scope of the >>> developers while providing the interface between the online world and the >>> offline world is not. >>> >>> >>> At this point the WebPKI and TLS are over 25 years old and they are the >>> only parts of the Web security infrastructure that actually deliver. The >>> only other Internet security protocol that is close to being a home run is >>> SSH and that is really just SSL for Telnet. >>> >>> Rather than constantly attacking the only parts of the system that are >>> functional, we would do a lot better to look at how Internet security is >>> failing. The big problem of Web Security is Phishing and that is a problem >>> because we still rely on passwords and the way we make use of passwords is >>> the worst possible way. >>> >>> The original security goal for the WebPKI was to make shopping online as >>> secure as shopping in bricks and mortar stores. That was all. Online >>> brokerages, banks were not part of it: We only had 40 bit encryption >>> because of the export controls. The whole issue was persuading Visa and >>> Mastercard to let merchants use the Web. >>> >>> What we missed (well I did at least) was the fact that 95% of Web >>> activity doesn't involve payments and never will (sorry Web3 people). So >>> the WebPKI was overbuilt for 95% of Web sites. But we didn't notice that at >>> first because doing RSA1024 was such a drag on the server that the only >>> people using SSL were the people who really, really needed it. >>> >>> So now we have a situation where the needs of the 95% of sites that only >>> need lightweight encryption with minimal endpoint authentication are >>> driving the whole show. The WebPKI designed by Michael Baum and Warwick >>> Ford has been more or less dismantled. >>> >>> Rather than going back, I think we should go forward. The WebPKI was a >>> technology of its day. We were working with limited machines and limited >>> technology. We only ever made authenticating the bank to the customer work, >>> TLS Client auth has never been practical because of the achilles heel of >>> PUBLIC Key Cryptography - we punted on the critical task of managing the >>> private key. And now that the user has dozens of devices, that is a >>> critical problem. Fido overcomes some of the issues of TLS-CA but not the >>> key management one. >>> >>> I have been telling people that Threshold Key cryptography is the way to >>> address this issue for six years now. First they said go away and write a >>> draft, so I did that. And then they said go away and write code, so I did >>> that. And then they said write an application that uses the code, so I did >>> that. >>> >>> What I want to do now is to take a look at that code and see if we could >>> use these ideas in existing Web browsers. >>> >>> >>> My model of the Web is different. In my model, the goal is to put the >>> user in control. So coming back to QWACs, the decision to use QWACs should >>> lie with the user and the user alone. It is not for the browser provider to >>> make that decision. Same for any root store inclusion: it is a user >>> decision. >>> >>> Now of course, very few users have the ability to make such decisions >>> themselves and the few of us who do do not have the time. So the real issue >>> is that the user should have the ability to delegate that choice to the >>> trust provider of their choice. >>> >>> In my view, curating CA roots belongs with Anti-Virus, DNS resolution as >>> a personal trust service. When a user acquires a new device, they connect >>> it to their personal account which in turn connects to their chosen trust >>> service provider. The user should have the ability to choose and to >>> re-choose. So if I choose McAfee and they muck up, I can switch to >>> Symantec, or to some open source collaborative effort, or to Microsoft, >>> Google or Apple or whoever else decides to offer such services. >>> >>> >>> The current code is a command line mode tool that only implements >>> catalogs for bookmarks, contacts, passwords, applications, etc. I will be >>> announcing that at HOPE Friday next: >>> >>> https://www.youtube.com/watch?v=zrBv717w8yY >>> >>> The main obstacle to implementing the trust service part of the scheme >>> is that it needs to be built around a browser which was impractical until >>> very recently when Microsoft started shipping WebView2: >>> >>> https://github.com/hallambaker/PhillsHypotheticalBrowser >>> >>> >>> The Mesh technology means that I can work from the assumption that every >>> device Alice uses is provisioned with the set of private keys and key >>> shares that enable her to do any cryptographic operation I might need. >>> >>> >>> >>> On Wed, Jul 13, 2022 at 11:08 PM Kathleen Wilson <[email protected]> >>> wrote: >>> >>>> All, >>>> >>>> This is just FYI that Mozilla has launched a campaign called "Security >>>> Risk Ahead" to provide information about eIDAS article 45.2, which (as >>>> currently written) could force browsers to accept QWACs even when they do >>>> not fully comply with browser root store requirements. >>>> >>>> https://securityriskahead.eu/ >>>> >>>> Cheers, >>>> Kathleen >>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "[email protected]" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/c10bc945-4b0c-4fcd-b438-98b0e4364f8bn%40mozilla.org >>>> >>>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/c10bc945-4b0c-4fcd-b438-98b0e4364f8bn%40mozilla.org?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- > You received this message because you are subscribed to the Google Groups > "[email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAMm%2BLwh8n-kRJW2TfWOjLh0EcFh5%3Dr6EViRMm6tNAR4zh4pc4g%40mail.gmail.com > > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAMm%2BLwh8n-kRJW2TfWOjLh0EcFh5%3Dr6EViRMm6tNAR4zh4pc4g%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- > You received this message because you are subscribed to the Google Groups > "[email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > > To view this discussion on the web visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/E1oCJ2z-0003IQ-1T%40submission02.runbox > > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/E1oCJ2z-0003IQ-1T%40submission02.runbox?utm_medium=email&utm_source=footer> > . > > > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/16346a5c-2cfc-4bcf-8729-3d6deb141eaan%40mozilla.org.
