Is keybase.io still mostly useless because it is not compatible with other key-exchange servers and can't be easily added to Enigma in Thunderbird?
If you are in Enigmail's Keymanager you can import from a URL when the content is well-formatted.
Examples that work:
https://keybase.io/snassar/key.asc https://pgp.samirnassar.com http://keys.gnupg.net/pks/lookup?op=get&search=0x69A75542488...
It would be nice if Keybase made the URL more easily "gettable" instead of hiding it behind 2 clicks.
Keybase was built to solve the "web of trust" bootstrap problem [1] by leveraging the web of social media profiles a user typically has with simple replicable proofs of social media identity.
[1] Arguably the hardest problem in PKI: how do you get user to trust that a public key is for the right person? In the classic PGP/GPG web of trust you do things like "key signing parties" and physical in real life interactions and deciding your threshold for how far you trust the friend of my friend signed this key. In the Keybase model you can see that the key (or family of keys) are tied to a certain combo of Twitter, Facebook, HN, et al accounts/profiles and generally trust that the person with all those accounts is the person you are trying to communicate with.
I still do not know what problem keybase.io solves when they allow uploading of private keys.
When the "right" answer includes "Print out this long thing, put it in a safe deposit box, and pray you never have to type in this long string of numbers", you immediately lose a lot of potential users; it doesn't quite fit the "Grandparent test" (could your Grandparent use it?).
Absolutely there's a trade-off in trusting a 3rd Party key escrow, but there's an immense usability benefit to average users that want something easier to do and "some security" really can be better than "no security", even if a lot of hard-line paranoid wonks have good reason to believe otherwise.
Ehh screw that. I'll write it in plaintext.
It's right in the key!
> Do I really need to copy the key or .asc address, wget it and import?
Is this a failure of keybase? You import it as with any other key, "decrypt from clipboard" in your favorite manager, or similar.
> How do I know if that's your latest key?
I don't know, how do you know that with a keyserver?
> Did not you revoke it last week and forgot to update keybase but didn't forget to update your blog?
Again, same as any other keyserver.
> THERE MUST BE AN EASIER WAY!
It seems that the frustration is with the PGP client, rather than keybase or the server, though.
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.)
Another example of the walled garden. You need their tool, whereas you can just use gpg with every other keyserver.
Maybe consider contributing to the effort?
Quick searched turned up several issues tracking the question:
https://github.com/keybase/keybase-issues/issues/327
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.
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.
I got really frustrated by this a couple weeks ago when I needed to get a key from a contractor but it was only on Keybase, which at the time I thought could be used as a GPG keyserver.
http://superuser.com/questions/227991/where-to-upload-pgp-pu...
Can someone please give examples of key-exchange services or server applications? I am getting a bunch of Microsoft exchange results when I try to google it.
Things to know about keyservers such as SKS: There is no way to remove keys or a way to really delete information. Uploading to know server will propagate that information to all SKS servers in the network over time.