From: Derek Atkins <warlord@MIT.EDU>
Date: Fri, 16 Dec 94 13:38:53 PST
To: ddt@lsd.com
Subject: Re: KEYSRVR: tabula rasa?
In-Reply-To: <ab15b73c07021003cae9@[192.187.167.52]>
Message-ID: <9412162138.AA16688@toxicwaste.media.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain


> Why is it possible for someone other than ME to add MY key to a keyserver?
> I realize that at some point (perhaps only the first time you submit a
> key?), there has to be some trust model employed, but it seems like this
> anyone-can-submit-anyone-else's-key situation offers a very obvious attack:
> anyone could propagate bogus keys across the net by just generating bogus
> keys with someone else's email/name on them, leading to massive
> impersonation problems.

This has always been there.  Many people consider it a feature.  I
like having the ability to tell a friend, who just signed my key, to
just upload it to the keyserver, since the signature tends to do much
more good being on the keyserver than being on my keyring.

Also, because the keyserver uses PGP as a back end, it is possible to
send multiple keys in a single message.  You cannot do batch-processed
incremental adds using PGP; if a keyfile contains multiple keys, there
is no way to have a program only add specific additions.

What about people who don't have email, or pseudonyms, or keys without
email addresses?  How do you deal with those, if you have to add your
own key.  And what about forged mail; I can easily send an email
message claiming to be you.  So what if I need to sign it?  If I was
creating a new key to spoof you, I _could_ sign it, and forge mail,
and it would be added.  So what?  What does this buy you?  Absolutely
nothing!

> Maybe I'm missing something obvious, but it seems like there should be a
> more rigorous method available to, and employed by, keyserver operators for
> verifying someone's identity before accepting a key submitted (supposedly)
> by them. Shouldn't the key submission msg itself at minimum be required to
> be contained within a signed msg from someone with enough "nearness" in
> trust levels from some trusted introducer known to the keyserver op? I
> thought this sort of situation was precisely the reason for the trust level
> system in PGP in the first place.

You are definitely missing something obvious!  I will absolutely not
do what you suggest here; I refuse.  If you want rigorous key
verifications then move into a PEM strict hierarchy (which I will
perfectly well admit has its uses) or patronize the SLED database
people, who will do what you want.

What I want to provide with my keyserver is an easy way for anyone to
distribute a PGP key easily.  I don't care who you are, what you
believe in, or what you want to accomplish, but if you want to let
people have your PGP key, I want it on my server so others can get it.

I think that many of the other keyserver operators believe as I do --
the role of a keyserver is key distribution, not key verification.
Key verification is done very will in PGP itself.  The method is
called SIGNING A KEY.  If you want to verify a key, check the
signatures on it.  This is exactly what the web of trust is about.  If
you trust me to sign keys, then you will trust the keys I've signed.
If you don't trust me, then my signatures mean nothing.  But you
should never trust a key from the keyserver just because you obtained
it from a keyserver.  That's just plain stupid.

> This may be a can of worms (or not), but if cpunks require fairly decent
> methods for verifying the identities of people who want to trade keys with
> them personally, then it seems keyservers should require at LEAST that
> level of verification (or better).

Again: ABSOLUTELY NOT!  Keyservers are open to everyone; all comers
welcome.  Everyone from "Pr0duct Cypher" to "BlackNet" to "Jeffrey
I. Schiller <jis@mit.edu>" is welcome to put their key on the
keyservers.

Again, there is a very big difference (which you clearly do not
comprehend) between key distribution and key verification.  The
keyservers ONLY do the former, and you should do the latter.  Doing
otherwise is, as I said, stupid.

> There doesn't seem to be any elegant mechanism available for doing this
> yet, but I'm ready to be educated on this point. Any comments?

Just add your new key to the keyservers and have people start using
it.  Life goes on.  You are not the first to be in this situation, and
you definitely will not be the last.

I hope I've given you some insight.

-derek

         Derek Atkins, SB '93 MIT EE, G MIT Media Laboratory
       Member, MIT Student Information Processing Board (SIPB)
    Home page: http://www.mit.edu:8001/people/warlord/home_page.html
       warlord@MIT.EDU    PP-ASEL     N1NWH    PGP key available