setting primary UID of other's keys and allowing direct UID subaddressing
dshaw at jabberwocky.com
Fri Nov 16 07:00:50 CET 2012
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:
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.
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?
More information about the Gnupg-users