Hacker News Reader

- re. anonymous keys. There is no need for them to be part of the web of trust. If you really want them there it is then a common requirements for signatories to require at least a verifiable e-mail address bound to the person they know and are authenticating. But then arguably it's not very anonymous any more.

- re. multiple identities. cross-Signatures in the web of trust are done on individual identities, not the master key! So if you sign an identity and the key owner then creates another, that new identity will not carry your signature.

- re. key parties: so far it wasn't an issue because it was implicitly assumed that people attending a key parting were savvy enough to understand how to sign. For PGP to be democratized the concept of key party needs to evolve. I personally combine them with a small lecture on PGP use, and say "you get to sign each other only if you have attended the lecture including its small practical".

- re. software keys. These are typically considered as an extension to the developers' keys. You as a user shouldn't sign those.

> it was implicitly assumed that people attending a key parting were savvy enough to understand how to sign

It's not only about being savvy though. You trust the person to not misuse his/her key unknowingly or knowingly. If you only use marginal trust on a key signing party then it can be mitigated somewhat though. What's the usual trust level used on such a party?

Edit:

Then the Putty master key is misused according to you: https://pgp.mit.edu/pks/lookup?op=vindex&search=0x4F5E6DF56A...

I don't think pgp ever can provide validation that some person owns some email address. You're signing the uid/address on a key which people prove they control. You can ask them to send you a signed message from that address to prove it, but if they owned someone's key, they likely have access to the email too. Even if they don't emails are still very easy to spoof.

Regarding changing the uid, your scenario cannot happen (if I understand it correctly): you sign uids, not the keys themselves. That means you can sign specific uids. If they delete it and add another uid, it's not signed anymore. (also you can revoke signatures if someone starts misbehaving)

I really don't mean the email address but the real name. People normally verify real names when they sign someone else's key anyway. Of course there is the problem that real names are often not unique.

Email address spoofing is too easy, I don't think that "owning" an email address is reasonably verifiable.

I wasn't aware that people sign each others uid. What happens if someone's name legally changes? Does he/she have to rebuild his/her WoT? Of course you can send out an email from your old id that you name is changing.

"Signing a key" really means signing the binding of a uid to a public/private key pair. I had to look at the Open PGP spec to figure that out ;-)

The question is, how to do verify that a particular person is exclusive owner of a uid? Because the uid is just a piece of text, there is no general way that will work every time. It depends on what the uid is. Someone could put their Passport number in the uid and you could check the passport to verify that they own it.

Of course most people use an email address as a uid. There are some key exchange protocols that will give you a pretty good idea that someone controls an email address (although they may not be exclusive owner). Basically you email them with some information and then they email you back with an encrypted version of that information. While they can spoof sending the email, they can't easily receive the original information to encrypt it.

Generally speaking, online, email uids are what is most useful. You need to know that the person who sent the message has access to the email address in the uid. But if you are actually concerned about the identity of the person, passport numbers, etc are better uids.

A key can actually have many uids. You can add new ones at any time. But if you do, you need to get people to sign the new uids (because while they may trust that you control one uid, they still need to verify that you actually control the other uid).

How you decide that the uid is owned by the owner of the key is up to you and you are free to sign or not sign any key. The web of trust comes where someone else has signed the uid on a key. There is a kind of second order level of trust with that signature. If my buddy Fred has signed the uid, and I am absolutely sure that Fred will never sign a uid without making sure that it is owned by the owner of the key, then I will probably trust it. But if my buddy Carl signs it, I might think "Carl is not diligent enough to check it out", so I might not trust it as much. How you assign trust of third parties to sign appropriately is up to you (and you do it for each of the third party keys that may have signed something).

I hope that helps!

> But if you are actually concerned about the identity of the person, passport numbers, etc are better uids.

Why not just name + email? I don't think putting anything like a passport number is a wise idea. It's just putting one more semi-secret information on the internet.

I think the encryption and signing+trust gets mixed here. If I know someone only by email address, I don't trust their key very much. But I'm still going to use it to encrypt messages to them, because it's better than nothing. I'm going to trust it if it's got a track record of reasonable messages on mailing lists or git commits over some period of time.

But back to the main topic: email-only, and passport number are two extremes and the second one is even hard to verify. Most people actually just use name+email combination in uids. And that's what gpg invites you to do when generating keys. Why didn't you mention it?

The point is that the uid is just a string. You can put anything you want in it. Most people put their name + email because that's what is useful for most internet transactions. If you get an email from someone, you want to be able to verify that it is from the person who controls that email account.

For example, I work in Japan. My colleagues work in the UK. Generally speaking I know who they are because I work with them every day. However, I have never checked their real life credentials, because it doesn't matter to me. When I receive an email from them, all I am interested in is "Is this Joe Blow that I work with from the UK". I don't care if Joe Blow is their real name, or if their carefully cultivated story of growing up in Shouthampton and going to the London School of Economics is true (as opposed to growing up as an indentured clown in a travelling circus and escaping at the age of 14 on the back of an elephant). When I receive an email from them, none of that matters. I just care if it's the same person I worked with.

So most of the time people put their email address and a name (which may or may not be fictional). When I sign that uid against a key I am saying, "I verify that this person controls this email address and is the person I know as Joe Blow".

If you actually care about whether the person is who they say they are, then the uid is going to have to contain something more identifiable/verifiable. So for instance, let's suppose I'm a bank. I want to verify that orders coming from my customers are really from that person. It is important that it is really that person because there are laws about identifying where bank transactions originate. I don't care which email addresses they control. I don't care if they are spoofing their email address. What I care about is that any messages I receive from them are really from them (and that any encrypted messages I send to them is really only readable by them).

So a passport number would be a good solution. The person walks into a bank with a USB key containing their public key with a passport number uid on it. The bank physically checks their passport to see that it matches and that it does, indeed, belong to the person who claims that it does. It then signs that uid against the key and locks it away somewhere. The key never has to be on the internet. Why would it? Nobody on the internet cares who you really are (apart from the NSA, I guess). They only care that you are the person who owns a particular email address.

I agree that there is a lot of confusion over encryption, signing, trust and identity verification. To a large part, I blame the convoluted nature of Open PGP and the existing documentation which conflates many, many issues.

I don't understand why do you want to sign that UK person's key in the first place. You can't verify who they are and only communicate online. Ok - that sounds to me like you shouldn't announce "I trust this is a real name/email" in that case. You can trust it privately and still use the key anyway.

But nobody is forcing you to sign the key, or even then to publish that information on the internet. As you say - how do you know they're that person?

(I'm ignoring the part of - should we even care that the identity matches. You communicate with the (person, key) tuple - you can still trust that tuple and not care if the name matches government documents)

A bank is a slightly different case. Your key for communication with the bank is (usually) more interesting than the key you use for emails. The bank also has both interest in protecting communication and means to do something better than key signing. Some banks will actually issue you a smartcard (or some equivalent) from which you can't export the private key at all - it may even be a gpg key. The point is - that's a much better protection on average, because an average bank customer has no idea about gpg, but will likely not give the smartcard away to someone random. Finally, few people have passports and you shouldn't be required to have a passport to have a bank account.

You're correct, and I think this is part of the growing disgruntling about PGP.

The most successful deployment, Debian, is a closed system: while Debian developers' keys and signatures are on the standard public keyservers, for Debian membership and archive authentication purposes, only signatures from existing Debian members count, and only keys explicitly pushed to Debian servers are usable. So it is possible for Debian to demand a specific meaning for signatures (which, possibly surprisingly, is "I have verified that the government associates this name with the holder of this private key": https://lists.debian.org/debian-devel/2009/06/msg00787.html), and it can hope that its members use a compatible definition when signing other members' or prospective members' keys. But Debian does not read trustworthiness, either to sign other keys or to generally be a good person, in PGP signatures. That's set by being / becoming a member of the project, which is no one's individual decision.

Leaving aside trust, keysigning parties have increasingly been sounding to me like an invitation to show up with fake ID and find some people who've never met you before. Possibly while everyone is drinking. They're also sort of a weird habit for a privacy-loving crowd, since they involve publishing non-deniable records of who met who, but hey.

To be fair, none of this means that the PGP protocol is bad, or even the GnuPG software is bad (although GnuPG sometimes seems like it wants to make the web of trust even murkier than it is). It just means that the public web of trust is useless, and you either need direct key exchange with those with whom you want to communicate, or some sort of organization that you trust to verify keys for the purpose at hand. For instance, if you're doing email within a company for company purposes, letting the company track keys is probably totally fine.

Huh, I didn't know about the Debian rules. But Debian keys and signatures are published to public keyservers too, aren't they? So your trust paths that contain a Debian developer may not guarantee the trustworthiness of the endpoint.

I thought that bootstrapping my trust from one of the Debian developers would make sense, since I already have Debian installed (somewhere you have to start). Looks like it's not that a good idea.

Yeah, a trust path that is end-to-end all Debian developers is fine. And I sometimes know that a certain human (that I don't have a way to meet with in person) is a reasonable human being, so I'll trust a path to that human that consists of Debian people, or other people I personally know to be reasonable human beings.