Modified user ids and key servers and a possible security risk?
kgo at grant-olson.net
Thu Aug 26 01:27:58 CEST 2010
On 8/25/10 5:49 PM, Daniel Kahn Gillmor wrote:
> On 08/25/2010 03:28 PM, Grant Olson wrote:
>> (1) Verifying that the keydata hasn't been tampered with, like editing
>> in a hex editor?
> this isn't very meaningful -- data is data, and you can't actually tell
> if it's been touched by a hex editor.
I was thinking of that for the case where Tomas, the OP, managed to
upload a key to a keyserver that gpg was rejecting as invalid. Should
the keyserver reject something with a corrupt sig in advance? But I
guess you're already talking about that below...
>> (2) Only accepting keydata that has been signed by the key owner?
> for self-sigs of algorithms that the keyserver understands, that's
> certainly a reasonable requirement. This would allow keyservers to cull
> bogus self-sigs, bogus primary key revocations, and any associated data
> (e.g. be willing to drop any user ID that has no valid self-signature
> associated with it).
> And that's *just* for the self-signatures. Deciding how to cull the
> non-self-signatures is an even larger can of worms.
The one big use case people throw around for keyservers with crypto
support is that keyservers could then honor the 'keyserver no-modify'
flag. I'm not really too concerned with that, but I guess I'll frame
the conversation as that being the killer feature that crypto would
I was originally thinking, "How do you verify third party signatures?"
and the initial hacky answer seemed to be have the submitter sign the
keydata, not with a self-signature, but with a standard signature on the
whole file. Less hacky solution proposed below...
>> (3) Possibly accepting keydata signed by trusted keys, for example peer
>> keyservers that that also perform the same verifications?
> ugh, no, please. i'd rather not turn keyserver operators into
> certifying authorities. This would also introduce massive syncing
> problems, since each keyserver operator might choose to rely on a
> different set of peers, and would therefore accept a different set of
I think for this and (4), I was out-thinking myself. How would
keyservers trust each other enough to sync? Or re-create the chain of
custody? Would a pool of servers even be possible since syncing is
propagating data via a third party? I wouldn't want a solution where
you couldn't sync between two servers.
Anyway, after some googling, it looks like there's a third-party
confirmation signature type in the spec. I'm not sure exactly how that
works, but that seems like the less hacky way to deal with things.
A brief look at the rfc makes it look like I could certify the third
party sigs on my own keyring. If that's right, maybe that's the only
way a keyserver would import third party sigs when no-modify is set.
You could have the keyserver:
(1) Perform crypto on self-sigs, only upload a key if the self-sigs on
the packets check out.
(2) If the newly uploaded key has the no-modify flag set, only add
third-party keys that have a "Third Party Confirmation" from the
That seems like a reasonable solution if I'm understanding the
confirmation signature correctly.
Regarding a crypto algo that the server doesn't understand, or one
that's been flagged as 'weak' in the configuration, I think the server
would just have to reject that info.
"I am gravely disappointed. Again you have made me unleash my dogs of war."
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 559 bytes
Desc: OpenPGP digital signature
More information about the Gnupg-users