hashed user IDs [was: Re: Security of the gpg private keyring?]

[Ben McGinnes]

On 13/03/11 6:37 AM, MFPA wrote:
> 
> Whatever you do with user IDs is optional, since they are just a
> free-text field. And of course a user wanting to make their key
> match more searches could include extra UIDs with additional
> hashes. For example John Smith <john.smith573 at example.com> could
> include hashes of example.com and of john.smith. In any event,
> including the information in hashed form should make the key more
> likely to be found than if the info were not there at all.

There's something else about this which has been nagging me, how would
you address this:

Currently a user's public keyring contains easily readable UIDs and
can be examined in any way they see fit.  If hashed UIDs were adopted
it would be possible to have hundreds of keys in the keyring which
only display hashed UIDs when listing the keyring.  Some of these may
belong to people the user corresponds with, some may have been picked
up in order to try to verify the WoT and some may have been picked up
to verify signatures on correspondence (e.g. in mailing lists).

So, my question, how would you enable a user to display those keys
with known names or identities without searching for a specific key
belonging to a particular person?

Say I ended up with a couple of hundred keys using only hashed UIDs
and I know that around 40 of them are people I correspond with, the
rest are from signatures on mailing lists or whatever.  If I wish to
split those keys off from the others into a smaller keyring, instead
of leaving everything in the default keyring, how do I determine that
without wading through large email archives to find the key IDs of
those people I have corresponded with?

Also, when I am viewing the signatures on keys and I see signatures
containing hashed UIDs of other people I do know and also have keys
for, how do I know which one is which in order to differentiate them
from the hashed UIDs of keys I may have, but don't know the identities
of?

It could be done with a local db or address book which maps previous
key searches to the hashes and keys they match, but this seems to be
an additional level of complexity just to achieve a current feature
and could also be used to circumvent the entire idea if performed on a
large enough scale.


Regards,
Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20110313/6098aee9/attachment.pgp>