Hi Dmitris,"I don't understand how this is related to the discussion in this
thread."I just clarified what EU centric perspective means in terms of
millions of surrogate* QSCDs and QESCs in circulation today.* Surrogate QESC
means any eIDAS Article 28 (1) - (3) non-compliant ESC that is issued as QESC.
Similarly its true for QSCDs.BTW, I'm well aware of EU complaint procedure but
its a separate issue - in reality any attempt to initiate investigation fails
because of those private embassies mentenioned in my email. In this matter
Commission's public clarification should be very helpful.In short, the EU
centric perspective relying on so called SBs doesn't work - its not just SBs
under Directive 1999/93/EC (eIDAS), the same is true for data protection,
competition and other relevant sectors.Hope this helped.Thanks,M.D.Sent from my
Galaxy
-------- Original message --------From: Dimitris Zacharopoulos
<[email protected]> Date: 7/15/22 20:36 (GMT+02:00) To: "Moudrick M. Dadashov"
<[email protected]> Cc: [email protected] Subject: Re: Mozilla
Campaign: securityriskahead.eu
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.
--
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.
--
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.
--
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.
--
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/E1oCQ0k-0003Gb-Ix%40submission02.runbox.
