Re: A brief comparison of email encryption protocols

[Bill Stewart <stewarts@ix.netcom.com>]

At 08:03 AM 3/1/96 -0800, Eric Murray <ericm@lne.com> wrote:
>Suggestions?  maybe key:/pgp/slack.lne.com/ericm/key/asc?

>Finally, a question:  should the keyserver be able to serve
>keys in a way that is secure from a MITM attack, or can it depend
>on the certificate chain in the key certificate itself to
>validate the key certificate?  I think it can, but I am not
>sure, so perhaps someone smarter than I can explain why, or why not.

Web of trust is clearly the way to go, but it helps to have both.
1) You need Web of Trust anyway
2) You may have multiple signatures, by people other than the keyserver;
        issues like "Company X Authorizes Key NNN for purchase up to $D"
        are outside the scope of keyservers.
3) If the keyserver managers _want_ to sign the key, they can.
4) It's much more convenient to run a non-trusted keyserver;
        there's a lot less security paranoia required,
        and enough less work that more people will run them.

On the other hand, sending signed responses from the keyserver 
is clearly valuable.  The big MITM risk is for revoked keys;
the MITM may be able to block transmission of the revocation
notice or, for Certificate Revocation List models like X.509, the CRL,
and send an old key.  Having the MITM sign and timestamp the response
reduces the risk that an old self-revoked key will get through.