Specifically "check a signature". Even everyone that knows how to sign fail to really check anything. Honestly, if it aint boiled down to a green or red icon then people are going to misuse, assume security when its not, or just click "yes".
If you get a new public key for someone, and it's signed by someone else you don't know (most of the time this is the case) are you going to bother to utilise that signature to increase the trust? No. Are you going to assume increased trust somehow regardless? Yes. FAIL.
Modify it further, if it is signed by someone you do know what are the chances your UI is going to give you any sort of indication that this is more trusted that other message workflows? And if it doesn't give you any indication (most leave it up to you to check) who's gonna bother to look just passed "your friend <yourfiendsname@company>" ASCII and actually check the key? no one. FAIL.
I use PGP extensively. However, I haven't bothered with the web of trust, for the same reason I don't publish my address book for everyone to read, privacy.
I have already run into this at work. I have customers whose keys are publicly available, and others who should not be, and so I cannot effectively use keysigning internally to manage relationships. This is because I don't want to upload every key I know about to a public keyserver.
Maybe I am mistaken or maybe there's a way to do that without having multiple keyrings or something, but that's kind of the problem. It's really hard to tell what I would or would not be sharing because there's no "interface" to speak of and I am hardly an expert.
btw, how is a person signing a key in the usual WoT model supposed to know whether or not the email address specified in the key uid is actually controlled by the person standing in front of them at the key signing party with passport and key fingerprint in hand? Even if you carefully follow the recommended key signing procedure the binding which actually matters for exchanging encrypted email has very poor validation (or none at all).
If you only meant verifying the email as apart of a keysigning party, agreed. Meaning you are looking at their passport and sending an email at the same time. This is better than nothing but wont protect against many directed attacks. For instance, a journalists has to be more careful. Also, in the end if you are sitting in front of each other might as well just verify key fingerprints. Better privacy and security than a simple email verification.
If the author meant actually sending someone a email to see that it is indeed owned by them remotely: NO WAY. Does not work:
me: "hey, just sending you an email to confirm its really you before sending the secret plans?"
them: "yeah, its me. send the plans."
That is exactly what WoT tries to solve but can't due to misuse.
I think you misunderstand. After meeting someone and exchanging public key fingerprints, you verify their identity. This requires checking their government ID and making sure they really are who they say they are. Then, you verify the uid of their key by sending them a message encrypted with the figerprint you received in person. Only the holder of both that key and the email address can respond to your message. Then you can sign their public key and return it to them.
What kind of attacks is this practice vulnerable to?
> What kind of attacks is this practice vulnerable to?
I want to pretend to control target@example.com and the legitimate owner of this address is an OpenPGP user who has published a keyring on the public keyservers.
1) I create a keyring and add a single uid with my real name and target@example.com
2) I download the public keyring for the legitimate user target@example.com and extract the encryption subkey.
3) Even though I don't know the private key I can add this public key as the encryption subkey to the keyring created in step #1.
4) I publish this keyring on the public keyservers so that you will find it by querying the fingerprint I give you when we meet.
5) You send email to the real user target@example.com which they are able to decrypt and respond to. Of course there could be some confusion since the real user is not expecting an email which presumably talks about verifying keys.
6) Since the mail was decrypted and responded to, you sign the key and return it to me.
7) I revoke the certification on the encryption subkey I borrowed from the real user and add a new encryption key which I create.
8) People who trust your signature encrypt mail to target@example.com with the false key I've published.
> What kind of attacks is this practice vulnerable to?
So long as the trust only translates to the very limited use cases then there is no vulnerability. Those limits basically mean that no trust should be assumed by anyone that did not participate in the WoT in question. This particular style of WoT means anyone wanting to retain anonymity needs to skip it, or am i missing something?
Mainly I think all WoT models i've seen thus far are too susceptible to sybil attacks (impersonation) and as a result instill bad habits.
you only need to look at people use of pgp today to see how much WoT's would be a failure if used. pgp.mit.edu still aint got ssl. journalists are linking to nonssl links for their key via twitter t.to urls
If you get a new public key for someone, and it's signed by someone else you don't know (most of the time this is the case) are you going to bother to utilise that signature to increase the trust? No. Are you going to assume increased trust somehow regardless? Yes. FAIL.
Modify it further, if it is signed by someone you do know what are the chances your UI is going to give you any sort of indication that this is more trusted that other message workflows? And if it doesn't give you any indication (most leave it up to you to check) who's gonna bother to look just passed "your friend <yourfiendsname@company>" ASCII and actually check the key? no one. FAIL.
PGP WoT fails miserably.