Keep web of trust - Allow endorsements

[r000t]

PGP was built on top of a "web of trust", expecting that users would sign the crap out of each other's keys to replace a centralized certification authority. It's why a service like Keybase hasn't existed before. The problem is that this isn't exactly user friendly. It's arcane and confusing.

Keybase should keep with that tradition, and make it easier, too.

You could call it sign key, but that might be a bit confusing. I'd call it 'endorsing' someone's key. You endorse a key if you know a person, and know that these are their accounts, and you further endorse it (remember the varied levels of trust in GPG?) if you've met them in person and have verified their fingerprint.

An endorsement would be the same as a key signing; Keybase (or the CLI application) handles the heavy lifting of signing the key and uploading the signature. It could stay compatible with people on the old 'web of trust' system by adding these signatures to their .asc file available on Keybase.

Added to the 'tracking' and 'tracked by' lists would be 'endorses' and 'endorsed by'. Under the proofs could be something similar to "This user's key is endorsed by 8 people, 2 of which you trust."

The documentation should make it very clear what an endorsement is and what it's not. It's not one confirming that one likes or is a fan of a person, it's one saying that they have personally talked to the individual, verified their identity (with varying strengths selective, from on the phone to inspected photo ID), and compared key fingerprints. Yes, you're still relying on people to be honest, but they should still be aware of what they're saying.

One should also be able to trust and not trust endorsements from a given user, based on how likely they believe that user to practice good judgement when endorsing other users keys.

Good idea?

[orcmid]

I agree that there should be better coordination with PGP key servers and the web of trust out there. This also makes the functionality of keybase.io a bit more distributed.

The GnuPG parlance is "certification" of another's public key. I think that is fine. I also think that integration could include periodic synchronization of the public key held at keybase.io and obtained from the PGP key servers.

The Apache Software Foundation already does this for the accounts of Apache Committers. I put my fingerprint in my account profile (not in a privately-writable), and the ASF system periodically fetches the public key and puts it in a roster of public keys that folks can obtain to verify signatures on codebases. The identifier association, in this case, is between my Apache ID (which appears ub an User-ID/e-mail pair in my cert), the fact that I have a committer account to which I presumably have a private password, and the fact that the particular cert appears on the committer public-key register. See https://people.apache.org/keys/committer/orcmid.asc
This is a weaker arrangement than the one with keybase.io to the extent that I never had to prove I possess the private key. However, when they required all committers to reset their passwords in the aftermath of Heartbleed remediation, the instructions were sent encrypted to my Apache ID e-mail address. Only if I still received mail there and had the private key could I obtain the special instructions, unique to me, for resetting my password.

I didn't check if it is reflected in that public key yet, but all of those e-mail addresses have also been verified at the PGP Global Directory verification service. There are individual certifications of each User-ID/e-mail pair that has been verified.

[sebastianw]

I agree to this. I would even go a step further: PGP has distributed key servers which power the web of trust. With PGP you can specify UIDs that look like a twitter ID or a github username. Why not use the existing PGP system and put the proving into the public key as a uid? And "tracking" is already implemented, just sign someones key. The keybase.io website could be a really great fronted to all of that but the information should be put into PGP so that is verifiable anytime even without keybase.io or the keybase.io client.

[vorpalhex]

At least the concept of endorsements would go a very long way. I think some of these things are much more difficult to implement then that, but a three click endorsement process would massively increase trust in a given user.

[viccuad]

I also agree to this. Keybase is in a very good position to make gpg usable by the public, and having the web of trust backed in it for people you meet in person, and tracking for 'unkown' people or for not die-hard users seems a good way to go.

I would call this concept 'trust', instead of 'endorsement'. That way, you can say you 'trust' someone, and at what level; no need to explain what an endorsement is or what is the purpose of it.

[malgorithms]

Just to share some of our thoughts on web of trust. I might be speaking more for me than @maxtaco:

• We like the idea of a web of trust, and we talk pretty regularly about how we'd like to do it at Keybase
• One concern is the possible confusion between it and tracking, which are certainly very different things. In fact, people coming in with an understanding of the WoT are often confused by the casualness of tracking (and this is why we made the https://keybase.io/docs/tracking doc.)
• We have some serious issues with the status quo for key signing

I think my biggest issue with key signing is that it's very confusing to anyone but the most technical users. I have in fact now been to a key signing party, where everyone was a programmer, and it was still a logistical nightmare. Further, there were a handful of people in the group whom I'm certain no one knew prior - of course everyone checked their ID's, key fingerprints, and human faces, but it would be pretty easy to insert yourself into one of these situations with a fake ID from a random faraway state. Further, I think these key signing events typically happen at conferences, meetups, etc., where there are always a lot of people who don't know each other. My point is:

1. I have a very hard time imagining the average user bothering with this process.
2. it would be very easy to get yourself strongly connected into the WoT graph where everyone says they did an "extensive review"
3. When faced with simply a list of who's signed a person's key and maybe some numerical values representing the strengths of the reviews, almost everyone will be pretty confused.

I'm sharing all these concerns because I'm wondering if there's something better that can be done that's designed for human consumption. This would require (1) a more curated process, and (2) a goal of making the statements more readable.

This isn't my ideal solution yet, but working backwards from the human ideal, what I wish for is I could see a signed statement in the web of trust like this:

Max Krohn (maxtaco)

"This is the same Max Krohn I've known since 1995, when
  we started college together at Harvard, and we made SparkNotes
  OkCupid and Keybase together. He read his fingerprint to me in person."
[expand for the full signed statement]
signed by f0434... twitter/malgorithms, github/malgorithms, etc.

Of course the full signed statement would be some kind of structured JSON object which would have his key fingerprint and other crucial details, and a client could review it and present me the text and details as I liked.

Clients that generated these statements would encourage users, through the UI, to generate a statement that contains 3 clear pieces of information: (1) how they know the person, (2) how they met up to do the signing, and (3) how they reviewed the key. The UI would drive users to make sure all of these 3 things would be collected, always.

I think one could argue that the more human it becomes the less easy it is to analyze the strength of connected edges in the graph. I think that's true to some extent. But I'm not sure the numbers that people are posting in the regular WoT are reliable. Second, for both safety and convenience having human readable explanations of those paths paired with provable public identities is powerful. If you want to find a strong path from user X to user Y and you can cross-reference the social media graphs each person along the way is connected to, you can produce (1) a very strong set of connections, and (2) a human readable chain of the statements, with links to the social media accounts of people along the way.

As an example, let's say you wanted to download some signed software I released. Even if you don't personally have a WoT connection to me it might be noteworthy to see a human endorsement from a known developer who lives near me -- whose twitter or github handle is well known -- because Keybase proofs ensure you're getting the right endorser, even without a WoT.

In summary:

• we'd like to make the process more human and less error prone
• the ultimate graph has 2 kinds of edges: human-human endorsements and human-identity proofs. Together that's a stronger graph.

[orcmid]

I think there are two issues that become comingled in WoT that do not show up in keybase.io itself.

The first is accepting that you trust the public key as being for a private key that is in the custody of someone known to you. That's what using PGP to "certify" that public key constitutes -- your attestation that you accept the public key as an identifier for the claimed person (i.e., some entity with which the User IDs are specifically associated). Keybase.io with its proofs of identifier associations (Twitter ID, GitHub account, etc.) is great for providing confidence in that respect. Of course, when you make your certification public, you are declaring to others that you trust usage of the associated private key as authentic.

The second aspect of WoT is how much you trust the certifications made by someone you recognize to be diligent in their confirmation of the identifiers of others (and equivalently, of how much others trust your declarations). You don't need to reploy on WoT yourself at all. Others regard it as some sort of ultimate truth and expect it as a confirmation of the certificate as an identifier. That is, they only want to see certifications of a public key by some minimum number of folks that they already trust to be diligent in how they certify other public keys as authentic. PGP provides a mechanical check on that in order to streamline that checking.

I find the keybase.io proofs to be much stronger than the WoT with regard to authentication. WoT does not require proofs of secret knowledge at all. Despite that, I run into blind trust of WoT as confirmatory with disappointing regularity.

I'm far more likely to certify a public key for which I have keybase.io-based confirmation that the entity having control of the private key has a particular keybase.io account and is proven to be the party that I associate with a particular proven degree of presence on the Internet. I can still rely on WoT also, but in many cases I don't have to because there are often proof-accompanied usages of keys that I can rely on.

I think I am repeating the differentiation Chris has posted about, without getting into tracking.

I support the request on this issue. I think it would be great for the public key held at keybase.io to be refreshed from an [Open]PGP public-key service periodically. This should not impact any proofs, it would then carry certifications from others (including highly-trusted sources), and revocations would be noticed.

For keybase.io users who are unaware of all of this, it should simply make no difference.

[risicle]

This is the only thing keeping me from making/recommending keybase as my central resource for identity.