choosing an encryption target from a User ID

[Daniel Kahn Gillmor]

On 09/22/2009 07:16 PM, David Shaw wrote:
> It doesn't work that way.  The default is "the first valid key".  It's
> been that way in the PGP world since before GPG as a product was
> written.  If you want to propose a specific alternative, I'm ready to
> listen, but I'm not going to defend the default behavior of 15+ years.

OK; if i'm proposing one specific alternative, it would be:

  Select the most recently-generated valid key that has a non-revoked,
  non-expired encryption-capable subkey, and has a matching user ID with
  the highest-available-class of calculated validity for the given User
  ID.

That is, if you have the following keys with matching User IDs and
non-expired, non-revoked encryption-capable subkeys (or
encryption-capable primary-keys):

 * A: unknown calculated validity, primary key created 2005-02-01
 * B: marginal calculated validity, primary key created 2004-01-02
 * C: full calculated validity, primary key created 2003-08-01
 * D: full calculated validity, primary key created 2003-05-02
 * E: marginal calculated validity, primary key created 2004-10-30

then C would be the most reasonable default choice for encryption, due
to its full validity and creation date.

If C and D weren't in the keyring, then E would be the next-best choice.

A simple algorithm for doing this is to walk through the keys in the
keyring with a matching User ID; keeping track of the "current best"
key.  When you look at a new key, compare validity with the "current
best".  If the new key has better validity, use it instead of the
"current best".  If the new key has worse validity, pass it over and
move on.  If the new key has the same validity as the "current best",
compare primary key creation dates: if the new key was created more
recently, use it instead of the "current best".

> It's used everywhere user IDs are referenced in the product.  --list-keys.
> --edit-key, --sign-key, etc, etc.

list-keys merely produces a list of *all* matching keys, and the
documentation makes no promises about ordering; i don't much care what
order they come out in this case.

For edit-key and sign-key, the proposed heuristic makes less sense;
there are already significant usability concerns with using either of
these subcommands when specifying a key by an ambiguous User ID, and i'm
not sure that this specific change would have any effect (good or bad)
on the usability of these commands.

At any rate, the usability concerns there seem less worrisome than the
security concern associated with sending data encrypted to the wrong key.

I hear you that the historic default is "first valid key", but there is
little documentation about keyring ordering in the man page, nor is
there any documentation that the in-keyring ordering can have
significant security consequences.

And i could find no documentation about how to change the order of keys
in any keyring.  Since the ordering is currently relevant in several
places, i'd assume there would be a way to change it explicitly, but i
can't seem to find it, other than the export/delete/import "push-to-end"
procedure i noted earlier.  Is there any other interface to change the
keyring ordering that i've missed?

	--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/20090923/9da46548/attachment.pgp>