by derefr | 2025-04-21 19:41:02+00:00
> 2. I've been programming and hosting websites for a decade+ and I would have no idea where to start with any of the things that you propose they "just" require.

That's because OV/EV certification are (currently) viewed/remembered mostly as "a bunch of bullshit that nobody sees the point in", and/or "a money-making scheme designed to allow big companies to throw money at the problem of looking 'more secure' than small companies, by showing up with a prettier lock icon/address bar state in web browsers" — ignoring the fundamental value provided by the design of the system, due to the pragmatics and politics of existing and previous (mostly previous) implementations of the design.

A site presenting an EV cert used to look like e.g. this in Firefox: https://upload.wikimedia.org/wikipedia/commons/6/63/Firefox_...

And this in IE/Edge: https://www.thesslstore.com/blog/wp-content/uploads/2010/06/...

Once browsers stopped visually differentiating sites signed by OV/EV certificates from sites signed by DV certificates with the big "green for go" coloration, corporations no longer had any motivation to get EV certificates, so everybody forgot they existed. This happened a decade+ ago.

(And then, in 2019, the last vestige of this distinction was removed, when EV certs stopped making browsers show the identified company name beside the lock icon: https://www.leaderssl.com/news/492-google-and-mozilla-will-s...).

Because of this, nobody today is really familiar with EV certs. But that doesn't mean they're hard or arcane; they're just obscure. And the process for getting one is clunky — but it used to be that the process for getting regular (DV) certs was clunky, too. The EV cert process just hasn't been updated with the times to match the ease of getting a DV cert, because nobody has cared to do so, because there's no demand.

But neither of those things mean that EV certs aren't fundamentally a good way to secure identity in a web of trust. Every code signing certificate is an EV cert, for example. And all cross-signed CA certs are EV certs. EV certs are still there, quietly underpinning much of X.509's security model, in TLS and elsewhere.

And as such, it's silly to recreate the EV validation ecosystem, but worse, for something (identity verification on BlueSky) that is pretty much exactly "the green address bar" use-case all over again — when we could instead just revive the dormant infrastructure that powered things the last time we cared about federated identity verification, and polish it up a bit for use in 2025.

> All of this would make it way too difficult to navigate verification for normal people

If they wanted, BlueSky could match what they're doing today by 1. setting up their own X.509 CA, and then 2. delegating the constrained ability to issue OV+EV certs to users from this CA, to named entities (like the NYT, as mentioned in the announcement.) Then you wouldn't have to do anything; everything could be handled on their end, with a BlueSky-CA-issued OV or EV cert just magically appearing bound to your BlueSky account.

(And they could — but wouldn't have to — get this CA into default trust stores of client devices. The BlueSky webapp backend would have the BlueSky CA explicitly in its trust store; as would any first-party native fat clients. Any third-party native fat clients would need to add the CA cert into the app and configure their HTTP client to use it. X.509 is not one global system; every X.509 root-of-trust creates its own tree-of-trust, which is only a web-of-trust insofar as multiple roots-of-trust can [but don't have to] cross-sign things.)

The point here is just that with X.509, big entities who BlueSky is unwilling to delegate identity-verification authority to, or who don't trust BlueSky — or, as BlueSky themselves say, the existing userbase at the point where BlueSky itself becomes adversarial to them — can step outside of this de-facto centralized trust model, by instead getting an different X.509 CA of choice to issue EV certs for any entities they want identity-verified; and then uploading (or in the case of a native app, installing) these certs to bind them to their BlueSky accounts.

In a bigcorp MDM domain, your EV cert allowing you to speak as @bigcorp_pr or whatever, would just get MDM-installed onto your device and you'd never even think about it. You'd just know that you actually can't log into that BlueSky account on any non-company device, despite knowing the password to the account, because no other device has the cert installed.

> and I'm not convinced it would do anything to stop determinated bad actors.

It does as much and as little as what BlueSky's announced approach — have human moderators check identity verifications using their common sense — does.

That's all EV validation is, in the end: collecting a bunch of information and then having a human look at it and say "yeah, this is really who should be getting certified to say they own this domain" or "no, this seems to be some kind of domain hijacking attempt." (Or even "this domain seems created to typosquat a popular brand, so I'm not granting the cert, even if the person really does own the domain." Denying typosquatters EV certificates is/was an explicit feature of most CAs' EV processes — although the term "typosquatting" hadn't been coined yet, so it was referred to as "trademark protection" or somesuch.)

The only difference, in leaning on X.509 infrastructure to do this, would be that you wouldn't have to rely on "BlueSky moderators" as your only group of people willing to put their reputations on the line to assert "yeah, this is who they say they are; they're really in charge of this business; and this business is a real thing—the one you'd think of when you see the name." You can go out and ask any company specialized in "having a reputation for making identity-validation assertions that everyone trusts" (i.e. an X.509 CA) to do it for you.