Hal <hfinney@shell.portal.com> writes:

The POV I am really arguing against is the one that defines identity to be a key, that states that in communicating with a key you are by definition communicating with the person you have in mind. The man in the middle attack does not exist because from your point of view the entity at the other end of the communication channel is just the MITM plus the person you think you are talking to. This idea has been expressed many times by other people in this discussion, and it is this which I think is fundamentally flawed and even dangerous because it encourages the use of untested keys. In fact it seems to define away the question of whether a key is real or fake.

It defines away the question of whether a key is real or fake because the key itself can not be fake. Assuming strong encryption anything that you send to the key can only be read by the key and anyone that he/she choses to pass it on to (something that can not be stopped). The only thing that can be fake about the key is the attributes associated with it - whether the attributes concerned are true names or the ability to use a bank account. Having a man in the middle when no attributes are concerned is simply the same as talking to someone who passes all of your messages on to a friend and then expresses the friends opinion rather than his/her own back to you... something that I can think of no possible way to stop. So although you are talking talking to A the opinions expressed are those of B, and there is no way of telling - in the same way as a man in the middle attack (B may not even know that his/her arguments are being used by A against you). This argument reduces the problem to 'how do you validate key attributes' as you can be sure that you are communicating securely with the key (key's owner) but nothing else. With PGP currently the only attribute that a key (X) may have is a name (true/pseudo) and this attribute can be signed as valid by another key (Z). If you accept the signature all you are doing is saying that you accept the signing key's certification - ie an attribute signed by this key (Z) is true. Eventually you have to just trust a key to have taken reasonable care to ensure that any attribute that it has signed is true - whether you are using a Web of Trust model or a more centralised model such as accepting VeriSign certificates (or your own - knowing exactly how much care you have taken to ensure that the attribute that you have certified (signed) is true). I believe that this is more removing a special case (treating the true name differently from any other attribute) than defining away the problem - even though the (MITM) problem does cease to exist. Jon jbaber@mi.leeds.ac.uk http://www.chem.surrey.ac.uk/~ch02jb/