"No-Keyserver" (and other) flags on keys
kgo at grant-olson.net
Mon Jun 28 04:10:46 CEST 2010
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 559 bytes
Desc: OpenPGP digital signature
More information about the Gnupg-users