Good day, PhillipIf 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,

[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=zrBv717w8yYThe 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/PhillsHypotheticalBrowserThe 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.

Reply via email to