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

[Daniel Kahn Gillmor]

On 08/25/2010 07:27 PM, Grant Olson wrote:
> On 8/25/10 5:49 PM, Daniel Kahn Gillmor wrote:
>> 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.

That makes sense.  i wasn't originally trying to be that ambitious, but
i see where you're going with this.

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

yup, that's a clever way to get rid of the non-self-sig case entirely --
by turning them into self-sigs effectively.  So you guarantee that you
have the public key material available to check the certifications with
anyway.

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

i think you mean "only add *non-self-sigs* that have a "Third Party
Confirmation" from the original keyholder".  But yeah, i think this is
an interesting angle to pursue.

Would wide adoption of this kind of confirmation create another angle
that people could use to "force" signatures on a known text?  If so,
that might be a concern for digests that are known to have weaker
collision resistance (e.g. the kind of exploits used in the hashclash
efforts against MD5 back in Dec 2008 [0]).  Do other people see this as
a concern?

	--dkg

[0] http://www.win.tue.nl/hashclash/rogue-ca/

-------------- 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/6767417d/attachment.pgp>