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

[Daniel Kahn Gillmor]

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.

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

Note that there are some potentially weird corner cases here: if what
used to be an invalid User ID becomes valid at some point in the future
(because a true self-sig shows up), then other third-party
certifications over that uid+key will suddenly become acceptable.

It opens a range of questions, including:

 * How do we distinguish a self-sig from a non-self-sig? (the presence
of certain subpackets indicates that a sig must be a self-sig, but the
absence of such subpackets does not necessarily indicate a non-self-sig)
 * What about self-sigs that use considered-weak digests? (these could
potentially be forged by malicious parties)  and which digests are
considered weak?
 * What about self-sigs of asymmetric keys whose algorithms the
keyserver doesn't support?
 * If the above are policy questions for the owner of the keyserver,
then we have an additional protocol-level question for gossip peers --
how do we interact with gossip peers who make different policy decisions
than we do, or who have implemented different a different set of
asymmetric cryptographic algorithms?

And that's *just* for the self-signatures.  Deciding how to cull the
non-self-signatures is an even larger can of worms.

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

> (4) Possibly saving the signature as well, so peer keyservers can
> optionally perform the same verification at step (2) when you sync?

Pretty much the main job of the keyservers is to store signatures.  That
is, the contents of an OpenPGP certificate exist largely in the form of
embedded signatures over key material.  I can't think of any additional
data that a keyserver would need to request or save.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 892 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20100825/90c20f43/attachment-0001.pgp>