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

[David Shaw]

On Jun 27, 2010, at 9:23 PM, Dan Mahoney, System Admin wrote:

> On Sun, 27 Jun 2010, David Shaw wrote:
> 
>> On Jun 27, 2010, at 7:50 PM, Dan Mahoney, System Admin wrote:
>> 
>>>>>> It's effectively a no-op though, as no server supports it.
>>>>> 
>>>>> I'm looking into making mods to at least one server type (we run one locally at work), and commit them upstream.  If I'm going to wade into that muck, I might as well have multiple things to try to make work.
>>>>> 
>>>>> The change in the key file format is the "hard" part :)
>>>> 
>>>> Having keyservers support no-modify requires that they first support crypto at all.  That's a really big step.
>>> 
>>> The ones I've seen have enough awareness of what's in a key to pull a key apart and determine who's signed it, when, and when it's expired. Is there more than that to read these bits?  Again:step zero may be to determine what the internal format is.
>> 
>> Vastly more.  Keyservers are basically databases with a front-end that understands the OpenPGP key format.  They don't actually do any crypto math - just storing the key packets in the database and allowing people to search for them.
>> 
>>> 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.  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.

> 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.

David