"No-Keyserver" (and other) flags on keys

[Grant Olson]

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...
Name: signature.asc
Type: application/pgp-signature
Size: 559 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20100627/70265520/attachment.pgp>