Key selection

[Sandeep Murthy]

Hi

I didn’t mean to suggest that `gpg` should do any guessing in this
situation.

Maybe I’m wrong and this is a minor issue, but from
a simple request-response model point of view when
`gpg —edit-key` is invoked by a user with an argument which i
not a specific key ID but an email which is associated with
multiple keys in the keychain then it seems it should certainly
not cause `gpg` to point to any revoked or expired key, as is
happening now (for me anyway).  This is clearly a bug, and
surely there’s an easy fix for it - check whether there are
any active (non-expired, non-revoked) keys, if so present the
list to the user to choose, if not print an appropriate message
that would cause the user to either generate a new key for that
email, and edit that key, or do a lookup on another source where
they have stored keys.

This issue is specific to the command line program, not any
GUI based program like Keychain (from MacGPG2 suite), because
there the user can see the keys and know which one to edit.

Sandeep Murthy
s.murthy at mykolab.com



> On 31 Dec 2014, at 16:54, Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
> 
> 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: 873 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </pipermail/attachments/20141231/16490394/attachment.sig>