The campaign against eIDAS regulation is a bunch of disinformations, invented by Mozilla and GAFAM. Specifically, the regulation does not introduce any “backdoors”:
@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.).
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.
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:
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.
@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?).
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.
@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.
@kravietz @Natanox @europarl_en @EU_Commission
One more thing on the topic of process: IIUC (based on excerpts) eIDAS only provides for a procedure to dispute validity of individual certs, but not of a CA. Currently, CAB forum does distrust CAs if they repeatedly misissue certificates, esp. if that happens after they claim to have fixed the problem that later causes misissuance. Also, this is not only important when it happens, but even when it doesn't happen the possibility shapes CAs' behaviour.
Well, at the same time the QCA behaviour is primarily shaped by financial fines imposed by the relevant regulators. That to me represents yet another - and higher - layer of scrutiny of QCA as compared to WebTrust/CABForum. E.g. in Poland they’re subject to financial fines described in article 46-49 of the Dz.U. 2016 poz. 1579 regulation:
https://isap.sejm.gov.pl/isap.nsf/download.xsp/WDU20160001579/T/D20161579L.pdf
@kravietz @Natanox @europarl_en @EU_Commission
Would they apply to issuance of pure DV certs?
Of course not, because DV is incompatible with QWAC by the very legal definition of the latter - see Annex IV of Regulation (EU) No 910/2014 (eIDAS).
DV is DV, QWAC is QWAC, these are separate realms.
@kravietz @Natanox @europarl_en @EU_Commission
So, the new EU regulation forces browsers to trust these CAs for DV, and you're saying that the regulations these CAs are held up to does not apply to their activity when they mint purely DV certs. For reasons of multiheaded cert chains being ~unsupported there is no distinction between trusting for EV and trusting for DV+EV. Am I missing something?
No, why "trust these CAs for DV"? EU TSL roots would only sign QWAC certificates, which by their specification cannot be DV.
@Natanox @europarl_en @EU_Commission
@kravietz @Natanox @europarl_en @EU_Commission
Any valid HTTPS cert is, possibly among others, a DV cert. If you present a cert with no domain name, IIRC the client must reject it.
HTTPS also does not have a concept of a cert where different root CAs attest different parts of it. So, we'd need to trust domain names from certs issues by these CAs or not trust them at all. So that regulation forces browsers to trust domain names from certs issued by those CAs.
I don't know whether regulations that those CAs are obliged to obey would penalize them for minting a cert with all EV-like properties valid, but a completely bizarre/unverified domain name.
> EU TSL roots would only sign QWAC certificates, which by their specification cannot be DV.
Do you mean that them signing a pure DV cert would be misissuance that can be penalized?
Yes, per the current wording the QCA cannot sign a pure DV certificate as it does not comply with the Annexe IV specification QWAC. And, unlike the commercial EV, there's a very tangible legal responsibility associated with such a violation.
Which is yet another reason why I don't buy the MITM FUD propagated by Mozilla — there's no way for a QCA to legally issue a fake certificate, as that would be a massive violation on so many layers, because every single Subject field would need to be faked, not only CN. And there's no way for any Member State government to absolve such a QCA even if they wanted.
@Natanox @europarl_en @EU_Commission
@kravietz @Natanox @europarl_en @EU_Commission
I mentioned the case of a cert where everything is fine apart from the domainname in subject name/subject alternative name, which you don't address.
@kravietz @Natanox @europarl_en @EU_Commission
And, now that I think of this more, what does "wrong" domainname mean? Normally this means "different than what DNS claims", with a dispute resolution system for impersonation etc. provided by the registry. If this is an attempt to add another dispute resolution system that circumvents (foreign) registries, then it's terribly underhanded and would create problems worse than the one it solves (the original domain holder would still have valid certs for their domain and likely be able to renew them, so if they could present them they could be same origin with the new domain holder).
The Annex IV you pointed at it very lackadaisical and doesn't resolve my concerns:
> Qualified certificates for website authentication shall contain:
> (e) the domain name(s) operated by the natural or legal person to whom the certificate is issued;
