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/a14d716d-a13c-8184-2eb1-9b1e2588a89b%40it.auth.gr.
