Re: Certificate proposal

[jbaber@mi.leeds.ac.uk]

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/