struggling with potential keyid conflicts

[Neil Williams]

On Tuesday 27 Jan 2004 2:01 pm, Jim Hurd wrote:
> GPG seems to handle keyid conflicts very awkwardly.

Only if you use the shorthand methods.
:-)

> I was playing a bit with the 0xDEADBEEF id (famously conflicted keyid).
>
> recv-keys downloads multiple keys with the same key id, but gpg only uses
> the "first" one (I don't know the definition of first, maybe it is date?).
> The only way to access the second (assume for the moment that user id's are
> identical, or also conflicted in a different way) seems to be to delete the
> one I don't want, then sign the one I do want.

Use a longer ID string - e.g. when I sign emails using the OpenPGP plugin, my 
key is shown in the KMail headers using the longer ID: 0x8801094A28BCB3E3 
which represents the last 16 characters of the key fingerprint instead of 
just the last 8 for the shorter ID of 0x28BCB3E3. It might be easier to 
remember but it is not unique.

If that conflicts, you could use the entire fingerprint.

>
> But is this a reasonable way to proceed? Am I missing some part of the

No.

> design idea here? I am writing documentation for GPG use for a group of

In your documentation, if you cover deleting multiple keys from a local 
keyring you'll find that GnuPG asks you to be clear which ones to delete and 
recommends the fingerprint in full.

--delete-key name
                 Remove key from the public keyring.   In  batch  mode  either
                 --yes  is  required  or  the key must be specified by finger-
                 print.  This is a safeguard against  accidental  deletion  of
                 multiple keys.

> organizations where it makes some sense to use keyservers to distribute
> keys, but the threat of forged keyid's is a concern.

The fingerprint (IIRC) is absolutely unique.


-- 

Neil Williams
=============
http://www.codehelp.co.uk/
http://www.dclug.org.uk/
http://www.isbn.org.uk/
http://sourceforge.net/projects/isbnsearch/

http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
Url : /pipermail/attachments/20040127/26f086f2/attachment.bin