Key selection

[Daniel Kahn Gillmor]

On 12/27/2014 02:41 PM, Doug Barton wrote:
> On 12/27/14 9:36 AM, Sandeep Murthy wrote:
> | I have four keypairs associated with my main email, two of which
> | are revoked and one expired. But if I try to edit the main key
> | associated with email by
> |
> | $ gpg --edit-key <email>
> |
> | then it invokes gpg and points to one of the revoked keys rather
> | than the active key. I have to explicitly give the short ID of the
> | active key to edit that key and get its fingerprint.
> |
> | Is there a way to change this, or I am doing something wrong?
> 
> No, and no. :)
> 
> If you have multiple keys that match a pattern (such as your e-mail
> address) then gpg is going to take its best guess as to which one you
> mean.

The short version of the story is that its best guess really isn't very
good for any existing version of gnupg.

Its "best guess" is just based on a linear scan of the keyring,
returning the first certificate with a matching user ID.  The linear
scan is based on the date that each key was first added to your keyring.

While this is a disappointing guess, it's also very predictable (within
one known keyring), and controllable.  One way to control it is to
export all the old keys to a file, then delete them from your keyring,
then re-import the file.  Now you'll have all the keys available, but
the first one in the keyring will be the one you want.  If you have any
local (non-exportable) signatures, make sure you pass "--export-options
export-local" when exporting them, and "--import-options import-local"
when re-importing the file.

------

Ideally, GnuPG would use more sophisticated mechanisms to select the
"right" key (e.g. by considering calculated validity and expiration and
revocation information).  And conceivably, it could return an error if
there were multiple matches.  These are fixes that are much more likely
to be possible with the keybox format used by the 2.1 series, though, so
if you want to see that happen, please try to test out GnuPG 2.1.  the
wider deployment it gets, the better chances we'll have to improve
matching in general.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20141231/d5a0c9ef/attachment.sig>