On 6/27/10 9:23 PM, Dan Mahoney, System Admin wrote: > On Sun, 27 Jun 2010, David Shaw wrote: >> >> At the moment, it doesn't. That would need to be addressed if you >> want keyservers to be able to reject a no-ks-modify key. One way to >> do it is to only accept key updates that are signed by the key >> itself. But, of course, to do that, the keyserver needs to be able to >> verify a signature... > > That's one way. Another is to do it the keyserver.pgp.com way, and > email the primary uid a cookie. No crypto required. RFC2440 doesn't at > all require that the authenticity be verified cryptographically. Correct? >
But then keyservers wouldn't be able to sync with each other. User X uploads to keyserver A. Keyserver B syncs with A. Keyserver B has no verification that the info from keyserver A was authorized by User X. That might be fine for some servers, but would completely break something like pool.sks-keyservers.net. I imagine that'd even be the same issue for a client that tries to honor the no-keyserver settings. I grab User X's sig from keyserver A, how do I know that User X authorized it? > However, I think you're still missing my question: is it necessary for > the keyserver to be crypto-aware if I just want a keyserver to reject > those keys outright? Is there crypto involved in reading that flag, or > is it just a simple parse? From reading RFC2440 it seems the latter, > but I certainly respect you've been doing this longer than I :) > The only way to know that the key came from an authoritative source, with or without a "don't upload" flag, is a self-signature.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
