"No-Keyserver" (and other) flags on keys
Dan Mahoney, System Admin
danm at prime.gushi.org
Mon Jun 28 03:23:47 CEST 2010
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
>>>> 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
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?
While we're at this, do the various keyserver client-implementations
provide any option for passing a human-readable message back to gpg? I
don't see anything in draft-shaw-openpgp-hkp-00, but that's long expired
(but good reading).
>From what you're telling me, it also sounds like keyservers don't actually
verify the signatures that are on a key, and that's left up to the client.
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 :)
Techie, Sysadmin, WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144 AIM: LarpGM
More information about the Gnupg-users