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

[Hauke Laging]

Hello,

I just noticed that I cannot set the primary UID of a key for which I don't 
have the secret key. From the perspective of an official certificate that 
makes sense but for the usage of a public key it does not IMHO.

The primary UID has technical implications and is the only shown in several 
cases. The key owner has his reasons for chosing this UID as the primary but 
these reasons need not make sense for some users of his key.

The primary UID may not even contain the name or not an email address. I 
created my new key with a primary UID which consists of my name and a comment 
only. This may seem stupid or disturbing for someone who has imported several 
of my keys.

I see absolutely no reason why the key owner should force the decision which 
UID is shown on the key user (the more as he probably doesn't even want to). 
Deleting the unwanted UIDs is not an option because they come back with every 
key(ring) update. Nor would this approach be very elegant...

But this is not just about visual appearance. Key information like preferred 
keyserver, policy URL and cipher/hash preferences are bound to the UIDs. It 
says in the documentation that these pieces of information are taken from the 
respective UID – IF the key is addressed by the UID. This is not a good idea 
if there are several keys with matching UIDs. I admit I was too lazy to check 
but I doubt that the email clients use the email address for key selection. 
The two programs I know (KMail and Thunderbird / Enigmail) ask you for the key 
to be used if you add someone to the addressbook or define a recipient rule. 
But they show you the key ID so I guess they select the key by its ID, too 
(which makes perfect sense in general). But if they do then the data of the 
primary UID is used because gpg doesn't even know which address the data is 
sent to. AFAIK it is not even possible to use both a key ID and a UID 
simultaneously to select a key. But this would be necessary for the intended 
result.


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

It seems to me that you need --list-options show-sig-subpackets to get an 
explicit statement of gpg which is the primary UID. I don't think that normal 
applications do that. Probably they consider the first UID output by gpg to be 
the primary (this formal status is not relevant to applications anyway).

Could be covered by (1) mostly but would be nice anyway:
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

That would be a simple change for the email clients.


Hauke
-- 
☺
PGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 (seit 2012-11-04)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 572 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20121116/93848936/attachment.pgp>