From: "Michael Graff" <explorer@iastate.edu>
Date: Thu, 15 Dec 94 17:00:04 PST
To: ddt@lsd.com
Subject: No Subject
In-Reply-To: <ab15b73c07021003cae9@[192.187.167.52]>
Message-ID: <9412160059.AA25877@du81-13.cc.iastate.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.

Yes, there are such possibilitied.

>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.

>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).

Sure.  Are you offering to do the coding?

>I'd like to CLEAR/REMOVE ALL keys from ALL keyservers that are:
>  - attributed to me by others (without my knowledge)
>  - added by others (unknown to me)
>  - purporting to have been generated by me)
>and start with a tabula rasa. Maybe in a few weeks, once all these (what I
>consider to be) bogus keys are GONE, I can add my actual key to a
>keyserver.

Until someone writes code to deal with owner-submission (or whatever)
you're SOL.  Even if all the operators were to delete all of your keys,
someone would eventually mail their entire ring to a server, and those
bogus keys would be back up again.

You mentioned that you didn't keep your secret key for one of your
now-defunct keys.  Why not?  Are the servers supposed to clean up after
you now too?

>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?

Do you know how to code in Perl?  Code submissions welcome.

--Michael

--
Michael Graff    Iowa State University Computation Center      Project Vincent
215 Durham                voice: (515) 294-4994           explorer@iastate.edu
Ames, IA  50011           fax:   (515) 294-1717           gg.mlg@isumvs.bitnet