[denton-scratch]

So $VLOP is compelled to accept QWAC user-certificates, if one user requests it? And QWAC user-certificates are issued by TSPs whose CA cert must appear in the root-store unconditionally?

That means there is nothing preventing $TSP from forging my certificate, and giving it to criminals/government-agents, and nothing to keep the TSP in line, because the single audit constraint is "Keep the Minister satisfied".

I personally don't have a problem with the idea of replacing passwords with user-certs, provided I get to generate my own cert with my own private key. But the evidence is that general users can't learn how to use certificates.

I hate passwords, but I'd rather use passwords than a user-cert issued by an unreliable CA.

[Jensson]

The "unreliable CA" you are talking about here happens to be banks and similar. Do you trust that your bank doesn't just steal your money? Yes, you basically can't function in modern society if you don't. These e-id's just piggybacks on that trust to also work on online sign-ins. Most people worry more about their bank account being compromised than their github, so if these CA's (ie banks) starts to abuse their position we would have way bigger troubles than someone stealing your github accounts.

[denton-scratch]

I see, QWACs are to be issued by banks. And websites are required to trust them.

So if the bank gets hacked, then presumably the EU will indemnify the relying website against any legal action for trusting an unreliable CA? Even if that website is in China/Russia/Belarus?

You seem to have read the proposed regulation, Jensson; the information you've given is not in the position paper. Any chance of a summary?

[sleevi]

The QWACs can be issued by anyone who meets the minimum requirements, which are substantially less than those required for TLS server CAs in browsers. So while it’s true that banks can issue these, in practice there are many small companies with fewer than a thousand or so certs out there which have the same requirement that they must be accepted.

The eID certificates do come with probative (legal) effect, but this is where it gets complicated.

If the CA is hacked or screws up, yes, the CA is liable. But only if you did everything you were supposed to, such as checking every element of the certificate. These certificates have a variety of fields, such as “liability only up to XX euros”, and you (the site or user) are liable if you use it for more than that.

PSD2 has shown that the standards are a nightmare to fully implement. https://wso2.com/blogs/thesource/all-you-need-to-know-about-... gives a useful overview of how it’s worked for PSD2, and the new Digital Identity Framework/eIDAS Revisions proposes to make that the approach the standard everywhere.

In practice, this means that the server accepting your certificate needs to implement all of this correctly (spoiler: they don’t), or they bear the liability if the CA gets hacked - and they can’t distrust that CA. It also means the CA potentially learns every site you visit, because the sites have to check with the CA (if using OCSP).

Of course, if the government themselves directed the CA to misissue - e.g. at the direction of law enforcement - no such liability would be presumed, because it was a presumably lawful issuance.

[denton-scratch]

Thanks. Your explanation is miles more informative about that than the original article.

[Jensson]

I've worked on identity infrastructure in an EU country, I know a lot of details how it works, the EU proposal is just an extension and merger of the local ones. I can just explain how the local ones works, I don't know the exact details of the EU proposal as I no longer work in that industry.