Sign arbitrary data with your SSH keys

> GitHub acts as a trusted third party here, and you have to trust them not to lie about people's public keys, so it may not be appropriate for all use cases. But relying on a trusted third party with a professional security team like GitHub seems like a way better default than PGP's Web of Trust, which was nigh impossible to use.

Hopefully that's a false dichotomy and the entire Free Software community doesn't end up reliant on Microsoft to host all our keys for us. The article goes on to mention key transparency, though, which does seem like the right solution.

I note that rekor (the transparency log implementation used by sigstore) already supports signing with SSH keys[0], so this TechRepublic article about it[1] from March (which lists only "GPG, x509 and Minisign") is already out of date.

[0] https://github.com/sigstore/rekor/blob/main/types.md#ssh

[1] https://www.techrepublic.com/article/a-new-linux-foundation-...

Its not like anyone has ever really come up with a good solution to key distribution. You either trust a central authority (pki), deal with the mess that is web of trust, or blindly trust your first connection and verify the person hasn't changed (tofu).

Honestly it kind of reminds me of the problem of defining "Truth" (in a philosophical sense)

All options are sucky in their own way.

I'd say that DNSSEC records coupled with something resembling WKD makes for a pretty good way to distribute information in a somewhat trusted manner.

Nothing can really replace out-of-band in-person verification because human perception is remarkably difficult to spoof against or MITM. Comparing keys found in two bands, e.g. DNSSEC records and WKD (using TLS verified by the wpki system), is close enough for most threat models: you'd have to compromise DNSSEC and a CA to break that system.

You're still just replacing one central authority with a different one [or i guess 2] (i assume WKD = web key directory, in this context). With the email domain owner (i assume different from the recipent) being a cenral trust point (and if you totally trust them, why not just use mta-sts?).

Now sure, depending on your needs, you might be able to get mild improvements by chosing a different set of trusted parties than the webpki's CAs, but i'm not sure its really that different at the end of the day.

DANE + DNSSEC is much, much stronger than our CA system; if you control the keys (let alone if you go all the way and self host your DNS and mail servers), then you cut out pretty much all the intermediaries you reasonably can. You still have to trust DNS at the end of the day.

MTA-STS depends on webpki and the CA system.

Since not everything leverages DNSSEC yet and it's tricky to implement I'd supplement records with something resembling WKD so you have two bands.

Another possibility is having clients fetch keys over both clearnet and an overlay network (e.g. Tor); this doesn't help if the web server is being MitM'd but at least you have to trust client endpoints a bit less.

The opposite thing is true. DANE is far weaker than the CA system; it is centralized and controlled by parties that aren't accountable for security (and, more importantly, haven't spent the last decade with Mozilla and Google's gun aimed at their head over security issues). DNSSEC's centralized governance can get away with that, because they are de jure owners of the DNS hierarchy, and nobody can make them accountable for anything. You can't revoke .COM. But Google and Mozilla revoked all of Verisign.

I trust Google and Mozilla more than I trust the world governments that control the DNS hierarchy, and I see the actual transparency mechanisms, like CT, that the WebPKI watchdogs have built; unlike with DNSSEC, they aren't simply a theoretical thing that could be built in the future, but rather operate today and have been responsible for numerous detections of misissuance.