setting primary UID of other's keys and allowing direct UID subaddressing

[David Shaw]

On Nov 16, 2012, at 12:02 AM, Hauke Laging <mailinglisten at hauke-laging.de> wrote:

> Thus I would like to suggest two changes to gpg:
> 
> 1) Allow a configuration (external to the key like the ownertrust) to set the 
> UID to be used as primary UID in the local system. In order to get the current 
> behaviour a new option would be necessary, something like:
> --use-real-primary-uid

This violates the spec:

   Implementing software should interpret a self-signature's preference
   subpackets as narrowly as possible.  For example, suppose a key has
   two user names, Alice and Bob.  Suppose that Alice prefers the
   symmetric algorithm CAST5, and Bob prefers IDEA or TripleDES.  If the
   software locates this key via Alice's name, then the preferred
   algorithm is CAST5; if software locates the key via Bob's name, then
   the preferred algorithm is IDEA.  If the key is located by Key ID,
   the algorithm of the primary User ID of the key provides the
   preferred symmetric algorithm.

and later:

   The symmetric algorithm preference is an ordered list of algorithms
   that the keyholder accepts.  Since it is found on a self-signature,
   it is possible that a keyholder may have multiple, different
   preferences.  For example, Alice may have TripleDES only specified
   for "alice at work.com" but CAST5, Blowfish, and TripleDES specified for
   "alice at home.org".  Note that it is also possible for preferences to
   be in a subkey's binding signature.

It would violate Alice's desires to use alice at home's preferences when emailing alice at work.  She specified what algorithms she wants for each location (say, for example, that her work has policies about which algorithms are permissible for work mail).  Changing which user ID is primary does something similar - it changes what algorithm will be used without her permission.

> 2) Allow a combined key ID - UID addressing scheme. As even the email address 
> can occur in several UIDs a clean solution would be to use "UID IDs" along the 
> lines of key IDs. Internally the UIDs are already hashed anyway (and shown: 
> field 8 of --with-colons output) so just take the last 32 bit of that hash as 
> UID ID. Key selection could look like this then:
> 
> gpg --recipient 0x1A571DF5/0x7AAE70CD --sign --encrypt

This is legal, but possibly overkill.   If the intent is to say "encrypt to user at example.com, but I want the one attached to key 0x12345678" then I'd do it as something like "gpg -r 0x12345678:user at example.com".  There is no need to use a hash of the user ID here, as it doesn't disambiguate any more or any less than the actual string does (given the same user ID string, you'll have the same hash each time).

That said, it does seem like overkill.  How much of a problem is this in practice?

David