A usability gap in fingerprint rendering and parsing

[Daniel Farina]

Hello list,

I was recently trying to encrypt a payload using fingerprints in my
keyring to most unambiguously identify a key, when I encountered the
following confusion.  After giving up trying to find resolution via
search engine I played with it a bit more I got it to work, but the
head-scratching is, I think, unnecessary.

Here's what I did:

gpg --list-keys --fingerprint

In the output is a line like:

      Key fingerprint = 560D 1AD1 81D9 81C2 D5D1  005F 10CA 1074 B50F 855E

However, one cannot paste that string into gpg --encrypt --recipient,
getting the "no public key" message, as one might expect.  One can
after removing the spaces, however.  Two of the more obvious solution
categories include:

* Removing the otherwise helpful padding in the spaces between nibbles
and decabytes

* Expanding --recipient parsing code to accept this format

Stepping back a bit, software and users that want to deal in
fingerprints might be very different than software and users who want
to deal in short ids and email addresses, and it might be nice to have
a restricted --recipient option that only supports safe, unambiguous
addressing of keys.  I think I'm in the latter category.

In any case, I think the output of the program should be, in this
case, usable as input.

Thoughts?

--
fdr