choosing an encryption target from a User ID

[Daniel Kahn Gillmor]

On 09/22/2009 06:30 PM, David Shaw wrote:
> I think the current behavior is the right one.  Otherwise we break
> however many baked-in uses out there (scripts, etc), to say nothing of
> having to explain to people why a particular key was chosen.  "We pick
> the first valid key" cannot be misunderstood or confuse anyone.

well, i'm living proof that it can confuse people, and that people can
misunderstand it.  It took me a while to sort out:

 a) what it was doing specifically (i originally thought it was sorting
by key creation date)

 b) how to change the ordering of keys in a keyring (so far, i've only
figured out how to move a given key to the "end of the list":

   gpg --export --export-options export-local $KEYID > tmpfile
   gpg --delete-key $KEYID
   gpg --import --import-options import-local < tmpfile

I suppose i could do arbitrary bubble-sort-ish reorderings with this
primitive, too; is there another way?)

 c) that gpg is even willing to settle on a key with a matching User ID
with no calculated validity (e.g. if i added a user ID of "Daniel Kahn
Gillmor <dshaw at jabberwocky.com>" to my key, even if no one else
certified it, then anyone who had met me before meeting you would need
to specify your key by key ID, instead of by e-mail address!)

> Yes, it's wrong for some situations.  But every behavior is wrong for
> some situations.  This particular "wrong" behavior has almost 20 years
> of history behind it.

I hear you.  I've offered some concrete examples of ways that the
current behavior breaks things.  Can you give me an example of a script
that has this behavior "baked in" to the point where adopting a better
heuristic would break it?

Also, i believe this behavior is *only* relevant in situations where the
user asks gpg to encrypt something to a name or User ID.  Is that right?
 or are there other circumstances in gpg where the "choose the first
matching User ID" heuristic is used?

Thanks for thinking through this with me,

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 891 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20090922/542c6343/attachment.pgp>