3 ms·

Given usernames-as-domains, is there a reason to not just piggyback this on the X.509 web of trust? After all, we already have an established and highly-monito

by derefr 2y ago

Given usernames-as-domains, is there a reason to not just piggyback this on the X.509 web of trust? After all, we already have an established and highly-monitored set of sibling "trust roots" — we call them Certificate Authorities. And we already have an identity-validation system coupled onto X.509 FQDN-as-CN (i.e. TLS) certificates — certificate validation levels. BlueSky could just: 1. require a domain username for verification; 2. require that the domain presents an Organization Validated (OV) cert for verification as a "public individual" (i.e. the kind with a "personal brand" — which usually implies "worth registering as an LLC"); 3. require that the domain presents an Extended Validation (EV) cert for verification as a corporation. ...and the whole problem of identity validation becomes outsourced, and federated, and decentralized. (Federated because multiple sibling CAs; decentralized because every computer administrator gets to decide for themselves which CAs their machine should trust.) --- A rebuttal might be that "EV certs can't be used for this, because EV certs are too expensive, take too long to get, and don't integrate well with automatic per-subdomain DV cert issuance via ACME." But (IMHO) that's not a problem to be worked around; that's a problem to be fixed. Why leave a broken generalized web-of-trust infrastructure sitting there unused? If an online casino can KYC/AML you in two minutes with a passport scan and a 3D camera photo, it shouldn't be impossible to do for OV+EV validation what we did for DV validation with ACME. (Ideally in such a way that you can do the interactive process once, receiving not a cert, but some kind of collateral; and then, later on, any ACME server should accept that collateral during an interactive domain ownership probe, to upgrade the DV cert it's issuing you into an OV/EV cert.) --- The other neat thing about this approach is that, in a "fat" native BlueSky app (i.e. not just an Electron wrapper), the app wouldn't have to trust the BlueSky service to say who's verified. The app could TLS-validate each domain username itself, to compute the appropriate badge for that user — just as a web browser does when you visit a website. And it would presumably use your machine's OS TLS CA store for that validation, just as (some) browsers do.

giaour 2y ago
BlueSky users are already kind of doing this. Members of the US House and Senate tend to use their .house.gov/.senate.gov domains as usernames, which is a very trustworthy signal that the account is legitimate.
rafram 2y ago
1. Hello it's me your good friend Amazon S3 [1] 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. 3. The OV requirement seems kind of hokey. There's no such thing as "worth registering as an LLC" — anything can be an LLC. You could have an LLC that just holds your dog's assets and call it Internal Revenue Service (LLC), assuming someone else hasn't already grabbed that name in your state, and that would be completely valid. All of this would make it way too difficult to navigate verification for normal people, and I'm not convinced it would do anything to stop determinated bad actors. [1]: https://chaos.social/@jonty/110307532009155432 https://chaos.social/@jonty/110307532009155432
- derefr 2y ago
  > 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_3_rc1_Extended_Validation_SSL_address_bar_and_certificate_detail.PNG https://upload.wikimedia.org/wikipedia/commons/6/63/Firefox_... And this in IE/Edge: https://www.thesslstore.com/blog/wp-content/uploads/2010/06/GreedAddressBar.jpg 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-stop-displaying-company-name-in-the-address-bar-of-the-browser 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.

by derefr 2y ago

giaour 2y ago

BlueSky users are already kind of doing this. Members of the US House and Senate tend to use their .house.gov/.senate.gov domains as usernames, which is a very trustworthy signal that the account is legitimate.

rafram 2y ago

1. Hello it's me your good friend Amazon S3 [1] 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. 3. The OV requirement seems kind of hokey. There's no such thing as "worth registering as an LLC" — anything can be an LLC. You could have an LLC that just holds your dog's assets and call it Internal Revenue Service (LLC), assuming someone else hasn't already grabbed that name in your state, and that would be completely valid. All of this would make it way too difficult to navigate verification for normal people, and I'm not convinced it would do anything to stop determinated bad actors. [1]: https://chaos.social/@jonty/110307532009155432 https://chaos.social/@jonty/110307532009155432

derefr 2y ago
> 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_3_rc1_Extended_Validation_SSL_address_bar_and_certificate_detail.PNG https://upload.wikimedia.org/wikipedia/commons/6/63/Firefox_... And this in IE/Edge: https://www.thesslstore.com/blog/wp-content/uploads/2010/06/GreedAddressBar.jpg 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-stop-displaying-company-name-in-the-address-bar-of-the-browser 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.