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