Modified user ids and key servers and a possible security risk?

[Grant Olson]

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

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

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

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.

-- 
Grant

"I am gravely disappointed. Again you have made me unleash my dogs of war."

-------------- 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/20100825/17c44cc1/attachment.pgp>