Read-only keyring and the keybox

[Werner Koch]

> F.e. http://wiki.fsfe.org/Card_howtos/Card_with_subkeys_using_backups
> states under "Known problems" that "[...] GPG will look for the first
> key in the keyring to decrypt things." What a hassle to set up a
> smartcard subsequently.

That is simply not true.  An OpenPGP message describes the key to be
used for decrytion by including the long key id in the message.  This
keyid is then used to lookup the key.  If it happens to be on a
smartcard, the smartcard is used.

The problems you may have is with messages also including keys with
wildcard keyids (--throw-keyids).  In that case there is no well
defined order of keys to try.  See this comment in g10/mainproc.c:

      /* FIXME: Store this all in a list and process it later so that
         we can prioritize what key to use.  This gives a better user
         experience if wildcard keyids are used.  */

It has nothing to do with the smartcards.

> Oh, why I'm advocating to use the fingerprint instead of the short
> keyid above: I've come across a case where fetching a key via the
> usual gpg --recv-keys 0xdeadbeef method yielded 2 matching keys (if
> you must know, check for 0x76B8337A on subkeys.pgp.net).

Of course there are duplicated keyids out in th ewild; use the long
keyid in your conf file or - as you say - the fingerprint.

> Needless to say that the wrong key was used in operation (that could
> have been attributed just as well to my setup) but people expect to
> get a single key, not each key matching the shortid format. So, to
> make a rather verbose story short: Please adapt documentation
> accordingly.

I don't understand this.  Key selection is matter of the mailer and
not of GPG.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.