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

[Dan Mahoney, System Admin]

On Sun, 27 Jun 2010, David Shaw wrote:

>>>> However, you raise another question: How does a keyserver know who is 
>>>> uploading the key?
>>>
>>> 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?
>
> Correct, but then, RFC-2440 or 4880 doesn't say much about keyservers at 
> all.  It's mainly a message format document.  Semantics of keyservers 
> are not specified beyond one or two minor things like the no-modify flag 
> and the "preferred keyserver" field.
>
> The difficulty with mailing the primary user ID a cookie is that it 
> pretty much means your server can't synchronize with any other server.

Keyserver A updating keyserver B for key "foo" would in essence be someone 
other than the owner, even if they're in the same "pool", as keyservers 
can have multiple names.  Assumably if I have enough sense to set my 
preferred keyserver url (either to a keyserver or to a private url), I 
know which keyservers are islands and which are pools.

I presently consider synchronization broken.  If there were only one 
network of keyservers out there, and I didn't have to search multiple 
places when trying to sign or request a key, I might think otherwise, but 
this is not the case.  See my alternate request about being able to use 
multiple urls in auto-key-locate, which I don't believe currently works.

I'm also not aware of how servers synchronize, but if it's a different 
protocol than the standard single-key-request protocol, then there's an 
easy metric to say "don't hand out keys with this flag via this protocol".

Perhaps if I get deeply into this, I could define keyservers which were 
aware of which other ones did verification.

> Since your server would have an entrance restriction, and the other 
> servers won't, that means that your server would have to either reject 
> keys from other servers (i.e. not syncing) or apply the same restriction 
> (email user IDs from keys that weren't uploaded directly to your 
> server).  keyserver.pgp.com solves this by simply not syncing to anyone 
> else.  That makes it a completely opt-in server.

I wasn't against this plan.  This was (as mentioned) for work on a private 
keyserver whose changes would be merged upstream.  Consider it an initial 
step toward the whole.

>> 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 :)
>
> There is crypto involved in showing that the flag is real - that the 
> keyholder set the flag, and not someone just setting the flag for 
> malicious reasons.

> For example, take the case of a key with the no-modify flag set (i.e. 
> the keyholder doesn't want the key on a keyserver).  The attacker takes 
> this key, and removes the flag.  He then sends the key to a keyserver 
> without crypto.  The keyserver sees the key has no flag, so accepts it. 
> This allows an attacker to violate the keyholder's requirements.  If the 
> keyserver had crypto, it would know that the key had been tampered with 
> and the flag removed.

At present, no keyservers respect this flag, with or without crypto.  So 
that's not much of a leap, anyway.  This "attack vector" exists now.  I'm 
sure more than a few people have been annoyed that their keys wound up on 
a server, as I had read in a previous (and very long) thread.

Without at all getting into the "flag" argument, do you feel keyservers 
should be verifying selfsigs before publication, or do you think they 
should remain "dumb"?  Both imply some problems, but your statement as to 
keyservers not doing crypto didn't seem to imply whether you're for or 
against it, and I'm curious.

-Dan

-- 

--------Dan Mahoney--------
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144   AIM: LarpGM
Site:  http://www.gushi.org
---------------------------