@Natanox

The campaign against eIDAS regulation is a bunch of disinformations, invented by Mozilla and GAFAM. Specifically, the regulation does not introduce any “backdoors”:

https://agora.echelon.pl/notice/AbOiM4RCpo4HpQzYzQ

@europarl_en @EU_Commission

@kravietz @europarl_en @EU_Commission I respect your opinion, however I rather believe sources I already trust (EFF, Patrick Breyer, Mullvad, netzpolitik.org, CCC members etc.).

@Natanox

I'm not surprised that US organizations such as EFF protests against QCA, because they are routinely biased towards US-centric, libertarian worldview where any private company is to be by default trusted and any government organization is to be distrusted.

I *have* read their arguments very thoroughly. I *have* read the draft regulation. Mozilla arguments are simply unfounded and largely misrepresenting the regulation. They are as relevant as the old Brexit "EU wants to regulate curvature of cucumbers" FUD.

@europarl_en @EU_Commission

@kravietz @europarl_en @EU_Commission Not comparable. While the company-based system also is shitty, there at least is *some* scrutiny as any CA has to trust the others likewise (still, not perfect). The root certificates supposed to be made by EU states HAVE to be trusted by browsers according to the proposal, no scrutiny allowed. You're basically trading Covid-19 with Ebola. Trusting a government can backfire as much or even more than trusting a company.

@Natanox

In case of certifying authorities the “scrutiny” is very well defined in the form of Certification Policy and Certification Practice Statement. Let’s take one QCA I know because I used them in the past - Polish Certum has been issuing qualified certificates since 2000’s, and their CPS can be found here:

https://files.certum.eu/documents/repsitory/1-cert-policy&cert-pract-state-qcs/CCK-DK02-ZK02_CP_and_CPS_6.2.pdf

If you scroll down to page 31, section 3 on Identification and Authentication contains the actual checks applied as part what you call the “scrutiny”. The whole section takes 10 pages of detailed legal text describing very thorough organisation identity checks performed as part of the initial registration (section 3.2), including official company databases registration documents, government identification documents of physical persons etc. That’s the level of scrutiny you get from a QCA.

Let’s now compare that to the CPS of existing WebTrust member, Google:

https://pki.goog/repo/cps/4.14/GTS-CPS.html#3-2-initial-identity-validation

Even if we take the highest level of validation offered by Google which is OU (organization validated), the checks and policies described in Google CPS is a tiny fraction of these applied as part of the above QCA. For example, company identity validation (section 3.2.2.1) performed by Google sounds rather miserably weak in comparison with QCA checks - Google will happily issue you a OV certificate based on “a site visit by the CA” or “an attestation letter”!

And it’s the same case with all other checks applied by both certifying authorities. In summary, the claim that #eIDAS offers lower level of scrutiny when issuing the certificates is exactly the opposite of the truth, because QCAs offer much higher legal and organisational level of checks which can be clearly demonstrated by the comparison of relevant CPS documents.

@europarl_en @EU_Commission

@kravietz @Natanox @europarl_en @EU_Commission

You are talking about the part where the certificate is bound to an organization name. I believe that part of the cert is basically useless, because (a) humans operating browsers won't be surprised by its lack (b) they have been conditioned to expect weird-looking organization names sometimes.

Over the parts of CAB forum history I've seen (I don't participate, just look at it once in a while) I haven't ever seen issues where a CA was issuing incorrect EV certs without also issuing incorrect DV certs. The latter did appear quite a few times, including cases where the CA tried to muddy the waters as much as they could.

For these two reasons I think that EV-like validation (i.e. validation that isn't affected by the domains the cert is bound to) is a complete red herring in the CA system. I understand that people want to make it not a red herring, but the immediate change here is making these CAs able to issue DV certs (or am I wrong?).

@robryk

Part of my frustration about Mozilla’s #eIDAS campaign is that this the first time in the last weeks that I’m actually having a fact-based discussion with someone on this topic. All discussions that preceded your pot were essentially people shouting “EU JUST WANTS TO MITM US” while I explained it doesn’t and they ended up with “oh but we still trust Mozilla”.

They key thing to understand is that the EU QC is not anything new, quite the opposite - it was introduced when SSLv2 was still a thing and web browsers had bugs like not checking X.509 critical constraints.

The level of technical and organisational maturity of QC standards is therefore much higher than WebTrust, but few people do realise that because QC has been little known outside of EU and inside EU it’s usually hidden in the backend of tax, pensions, e-voting or e-government systems. People use it, while not even realising they use QC.

As for the actual subject - yes, presentation of the certificate validation status was a huge topic in QC regulation since 2000’s. Web browsers obscure this layer because historically the level validation of WebTrust/CABForum was degrading rather than increasing due to two key factors:

TLS certs are being sold on the same for-profit basis as say potatoes and a phishing campaign is just as good customer as a legitimate e-commerce website
its customer base is the whole world and getting legal & organisational validation globally is extremely challenging due to the variety of legal systems

As result, a company that offered more scrutiny in EV issuance process naturally had less clients than one that just issued based them on an “attestation letter”. Welcome to the Gresham’s law 😉

As result, on the market where DV certificates issued to microsoft.com and mircosoft.com offer essentially the same level of legal and organisational validation, presentation of the company name is indeed irrelevant. Another cause was pure marketing: if people saw the actual, fully validated company names and their legal location on all the cryptocurrency ICO, NFT and other one-day “investment opportunities”, they would probably think twice about. That would be bad for business, including web hosting business and advertising business.

And this is why web users were indeed conditioned into accepting weird organisation names, and why the whole certification validation layer was historically reduced to a lock symbol, which is the lowest common denominator of all business models that the GAFAM industry is interested in.

The EU QC has however a completely different user base: it offers a very high assurance for both organisations and individuals, where you are given a legal equivalence of electronic and written signature. There’s no problem with properly presenting such certificates in web browser UI - the problem with EVs that were a commercial ersatz for QC was precisely that they were an ersatz that did not work because it didn’t make any sense if you could get a valid EV for a company registered in Sudan and it was presented in the same was as an US or EU registered company.

@Natanox @europarl_en @EU_Commission

@kravietz @Natanox @europarl_en @EU_Commission

If someone wants to make better EV, sure, I don't expect that to be very beneficial (because e.g. avoidance of misleadingly similar names across different countries is likely to be at least as large a problem), but I have nothing against it in principle (I might strongly object to implementations that end up imposing costs on unwilling participants, but I have no reason to expect any random implementation to be like that).

I don't get why the regulation has to compel anyone to trust those root signing keys, esp. for reasons unrelated to anything EV-like (yes, we can't disentangle that _now_, but I don't see why we'd want to compel that at all). I would understand the regulation compelling browsers not to trust any other root signing keys _for some subset of the org hierarchy_. We have a significant amount of history of the CAB forum to show that (a) CAs that have a reason for their existence that's not satisfied by another CA and that's relevant for HTTPS get accepted (b) CAs get distrusted in cases where they have demonstrated lack of will or ability to ensure appropriate verification before/procedure around issuing certs or to respond truthfully. Many of these cases relied on participants' knowledge about what's reasonable and about nonobvious potential consequences (v. all the amusing ways of detrusting future certs only), so I am by default doubtful that whatever procedure eIDAS provides for is going to be less manipulatable by the CAs.

It's not only GAFAD that cares mostly about DV. If the domain owner has no legal identity that is relevant (e.g. is a person), then they don't care for anything EV-like. A small business/organisation might also not care for EV, because it's just as easy for them to make people aware of the legal name as it is to make them aware of the domain (I'm not certain about legal names of 3/4 small local businesses/organisations that I could recall on the spot, but could recall the domain names of their websites). I expect that this is mostly beneficial for companies of the size of Ford or Migros, but for such companies the problem of international name near-collisions starts to appear (because the user is unlikely to reliably remember what country the company should be from).

Also, DV if important insofar it's trusted by browsers. Cookies, local storage, meaning of "same origin" are all bound to domains, not subtrees of organisation space. This make me consider DV as important for anyone who actually has users' private data and serves it back to them.

@robryk

why the regulation has to compel anyone to trust those root signing keys

Well, that’s the same class of problem as “why the regulation has to compel anyone to obtain user consent for cookies” 😉 The primary answer is: because otherwise they won’t, because it’s not in their interest. The interest of end-users is frequently contradictory with the interest of vendors, which was prominently demonstrated by their boycott of DNT.

DV if important insofar it’s trusted by browsers

DV is a great invention that does work, but the only entity it authenticates is hostnames, so it’s bound to the infrastructure level. And what is “trusted by browsers” is 100% policy decision, driven by browser vendors business interests… which was prominently demonstrated by their boycott of DNT and introduction of FLoC instead.

@Natanox @europarl_en @EU_Commission

Follow

@kravietz @Natanox @europarl_en @EU_Commission

> Well, that’s the same class of problem as “why the regulation has to compel anyone to obtain user consent for cookies”

(I assume you refer to gdpr and not the previous law about cookie consent.) That case is about an entity doing something that the user cannot affect in a way they might want to (e.g. use a service that requires log in for an actual reason without being tracked for unrelated reasons). Here, the user's choices are made more difficult: they are deprived of an easy way to make a particular choice and deprived of the possibility to delegate that choice.

> The primary answer is: because otherwise they won’t, because it’s not in their interest.

Whose interest? Browsers? I've seen CAs with a very weak reason admitted as root CAs (I've found those cases most often by following up the original inclusion of some CAs that turned up shady afterwards). I don't see why browsers would mind, and I don't expect them to mind on principle of preferring no changes, because they behaved differently up to now.

> And what is “trusted by browsers” is 100% policy decision

Srsly, if you call the collection of whatwg specs a policy decision, then no part of any protocol isn't one. "Server needs to know the client's IP address" is then also a policy decision.

Currently, anything web that deals in nonpublic data relies on the assumption that an entity can control a domain and be the only entity able to serve responses from that domain. It's impossibly to keep any sort of nonpublic state in a browser that's not accessibly to someone who can impersonate any domain.

Sign in to participate in the conversation
Qoto Mastodon

QOTO: Question Others to Teach Ourselves
An inclusive, Academic Freedom, instance
All cultures welcome.
Hate speech and harassment strictly forbidden.