OK, I clicked. Where is your email address? Was that stawros or stavros? Do I really need to copy the key or .asc address, wget it and import? How do I know if that's your latest key? Did not you revoke it last week and forgot to update keybase but didn't forget to update your blog? THERE MUST BE AN EASIER WAY!
Keybase has a pretty good command line tool and commands very similar to ones in the article we are commenting upon can be used to grab the public key of a Keybase user using just their Keybase username.
It should probably be easy to presume that if a user gives you their Keybase username they are telling you it's the easiest way to get their most up-to-date key(s) and revocations and that they are actively managing it. (Pretty much the same assumption any time anyone ever suggests to you a specific keyserver over just a fingerprint and keyserver roulette; that's probably the keyserver they actively check/update/revoke and will be the timeliest.)
Sure. It would be great if they supported both. The suggestion is to use their tooling because it provides a lot of added value, but yes, it would be great if they also provided a standard "dumb" PGP/GPG keyserver, too.
Maybe consider contributing to the effort?
Quick searched turned up several issues tracking the question:
I get it. I mostly just meant contributing extra emojis to the issue tracker.
Or if you read the issues you can see that there are some genuine concerns in there that you could help contribute to that would benefit the open source community as a whole, with the side effect of simplifying things for Keybase "as well". Primarily, from skimming, it sounds like the keyserver protocols are not as well documented and standardized as one would assume, running a keyserver from a fresh/new code base is a non-trivial matter with a lot of quirks/bugs to handle. So, who knows, maybe you could contribute to better documenting keyserver quirks, and pushing for better, less quirky, keyserver standards.
> Did not you revoke it last week and forgot to update keybase but didn't forget to update your blog?
Revocations are a big problem.
As browser PKIs have demonstrated, revocation lists are basically insane and absolutely Do Not Work at scale when keys are able to live for years.
The endgame with browsers was that the cert revocation lists basically aren't checked. Hooray.
More fundamentally, revocation (even if it was scalable) is fail-unsafe. If someone can block your connections to revocation info sources, they can get you to perform unsafe operations. It's not a stretch to say that this is an absurd problem when we're trying to roll out secure cryptosystems: a network DoS should not crack open my security.
This is something TUF -- http://theupdateframework.com/ -- tackles with their timestamped re-assertions. It limits the amount of time that you can fail-unsafe by after seeing a revocation... to a tunable parameter, perhaps days or even hours, instead of years. At the same time, you get to keep your long-lived keys (you don't have to constantly update everyone on new keys).
We should learn some tricks from TUF for our personal comms PKIs. It would solve a lot of problems.
https://keybase.io/stavros