Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
As long as Keybase is a single source of authority, it's a target for attack and coercion. That's a problem. Like SKS, email, Jabber, or any other large-scale piece of infrastructure, Keybase should federate.
This means that anyone should be able to run a Keybase server and have it be just as authoritative as the one at <keybase.io>. When someone uploads new or changed info to any keybase server, it should sensibly propagate between them.
This requires design changes. Right now, Keybase (presumably) stores a bunch of user-related data in an unauthenticated database. Keybase has user accounts, where Keybase authenticates users to allow them to change things. These are dangerous design features, but they can all be fixed.
It seems to me that keybase needs some clarity of purpose. Although mostly about discovery, keybase is implicitly stepping into the murky waters of key binding--the process of binding a human memorable identifier to a cryptographic key.
The existing methods of binding, Certificate Authorities and the Web of Trust, have both become recently discredited. So, it makes a lot of sense to experiment with new approaches.
There are numerous possible approaches. For example, CA system, TOFU, WoT, DNSSEC, Mail-back, network perspective, global append-only log, to name a few.
The method by which keybase supports external identity proofs can be reduced to trusting the CA system, albeit hedged by allowing multiple proofs from different domains. However, since keybase is centralized, it makes for a single target to direct any X.509 attacks against.
It is 2014. We can, and must, do better. There are a lot of ideas floating around for how to better address the binding problem. If federated, keybase could adopt a model similar to that used by Nicknym, where federated servers provide key binding services through a combination of TOFU, network perspective, and key endorsement.
How is what you're suggesting different than current PGP key servers? I guess they don't currently propagate keys, but that gets complicated around the edges. What do you do if two servers get two keys for the same email address at the same time?
Federation and decentralization can cause just as many problems as they solve, so we need to think carefully about what problems we're solving and what problems we've decided to not solve.
each server is authoritative for a particular identifier so a conflict would mean an attack has been detected. servers update keys from other servers based on a strict ruleset.
keyservers were designed to facilitate WoT. they are good for that, but not good for binding.
This was referenced
Mar 8, 2014
I think having keybase's verification methods as manually-auditable as they are goes a long way to solving this. I don't see anything stopping anyone from starting up a secondary service that posts verification blobs in the same format/method as keybase or even verifying keybase's gists/tweets themselves for their users (we trust that this is Alice using keybase, as demonstrated by <proof url>)
Is there any reason keybase would be averse to recognizing the same proof blobs from other services? The signature of the object proves key ownership and the content of the signed object gives an identity URL (