Modified user ids and key servers and a possible security risk?
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Thu Aug 26 04:02:34 CEST 2010
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
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
> 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 ). Do other people see this as
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 892 bytes
Desc: OpenPGP digital signature
More information about the Gnupg-users