robryk @robryk@qoto.org

@kravietz @Natanox @europarl_en @EU_Commission

OK, so I'm back to my original opinion of "this will not work as intended[1], might be harmful and contravenes the approach of giving people more choice as long as it doesn't harm others directly, but it's by far not the most important thing right now".

I would have really liked if this was aimed at creating a binding between domain names and identities, but eh~~

[1] because _everything_ in whatwg specs assumes that documents in the same origin implicitly trust each other and their own resources

@kravietz @Natanox @europarl_en @EU_Commission

> nothing in eIDAS prevents anyone, including Mozilla or Google, from monitoring and running checks on both their (CABForum/WebTrust) and QWAC certificates the way CT does

And yet we consider that to be insufficient for web certificates and require CAs to preregister their certs in sufficiently many independent CT logs.

> and result in a huge shit storm, that would in the first place impact the QCA that issued it and result in its removal from the EU TSL.

I am uncertain of the size of shitstorm and of this result, esp. when there's some kind of an excuse for the behaviour, esp. given the very imprecise definition of what's a valid domain name in Annex IV (if there was a document that was binding for the QWCA CAs (and whose contravention was likely to lead to their penalization) that specified this more precisely I would very likely change my mind).

I would also like to reiterate that _as long as untrusted entities can generate DV certs for your site_ any properties of your certs are mostly meaningless. First, those entities can MitM _some_ of the connections to your site, and TTBOMK browsers show the EV properties based on the connection used to load the actual document. Anything else could be loaded from someone presenting a different cert, or could have been cached since weeks ago (yes, this is a way in which cert expiry and revocation is kinda broken). Secondly, if the site gives some private data to the user, whoever has a DV cert for that site can get at that data with basically no user interaction (redirect them from any other site they visit to this site, etc.).

The only way these properties are meaningful is by providing a binding between the organization name and domain name.

@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;

@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

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?

@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?

@kravietz @Natanox @europarl_en @EU_Commission

Would they apply to issuance of pure DV certs?

@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.

@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.

@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

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?).