struggling with potential keyid conflicts
linux at codehelp.co.uk
Tue Jan 27 16:02:36 CET 2004
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
> 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.
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
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Url : /pipermail/attachments/20040127/26f086f2/attachment.bin
More information about the Gnupg-users