Why is ~/.gnupg/trustdb.gpg readable by all?

[George Sinclair]

Steven E. Harris writes:
 > The GnuPG manual mentions that the trust information is kept separate
 > from your public keyring, presumably to avoid spilling what you think
 > of others when you export your public keyring. I was surprised to
 > notice that the default permissions on trustdb.gpg are both group- and
 > world-readable. Should this file be more private? If not, what's the
 > motivation?
 > 
 > -- 
 > Steven E. Harris        :: steven.harris@tenzing.com
 > Tenzing                 :: http://www.tenzing.com
 > _______________________________________________
 > Gnupg-users mailing list
 > Gnupg-users@gnupg.org
 > http://lists.gnupg.org/mailman/listinfo/gnupg-users
 > 

Steve,

Bear with me a moment while I ramble away with some prefatory
rhetoric.

When a key is created, a trust value pair is associated with
the key. The first is the assigned owner trust, and the second is the 
calculated trust value. This is always '-/u' ('-' = No owner-trust
assigned or not yet calculated, 'u'=Ultimately trusted).

The first value (assigned owner trust) refers to the level of trust that
you -- the owner of the keyring -- want to associate with the given key
(how much you trust the owner to correctly sign another person's
key). This is what is stored in the trust database. If you don't
change this value, the trust database will not get updated. 
The second value (calculated trust) is always 'u' and cannot be
changed, though the first can be using the --edit-key option.
This is the value that was calculated or assigned at creation. After all,
why wouldn't the key be ultimately trusted by the user who created it,
right?

Lets suppose, however, that you want to assign a non-default value to
the owner trust for a given key, perhaps one you imported. In this
case, the trust database gets updated. However, when you export the key, it
will be ALWAYS be imported on the other end as '-/q' (q=Undefined).
This is because GnuPG always assumes an initial calculated trust as
being undefined since the key wasn't created on home turf and the
owner trust value, of course, is NEVER carried with the key. GnuPG
requires this to be locally set so by default it's going to be '-'.

Another way of looking at this is that the person on the other end
does *not* have access to your trust database. In a sense, the key and
the trust database are mutually exclusive. Only GnuPG can link the two
and only if they're on the same machine in the same .gnupg directory
(or links from this area). A typical example follows:

<<< Here I'm playing with fictitious users Joe and Susan >>>
1. I import Joe's key (comes in as '-/q') - trust database *not* changed.

2. By whatever means, I verify that this key indeed belongs to Joe
   and is not spurious. I then sign the key. Joe's Key value pair changes to
   '-/f') so the calculated trust is now 'f'. Trust database, however,
   has still *not* changed!!!

3. Since Joe is such a swell guy, and I trust him to the ends of 
   the earth, I decide to knight him by granting him permission to
   verify other users keys. So, I change the owner trust value for Joe's
   key from '-' to 'f' using --edit-key. The value trust pair for
   Joe's key has now changed to 'f/f'. At this point, the trust
   database gets updated with the new 'owner-trust' information.
      
   Basically I'm saying that because I trust Joe, I also trust any
   keys that he might sign and hand to me. In this fashion, I don't
   have to sign say Susan's key to verify files signed by Susan if
   Joe had previously signed Susan's key. In essence, I can now
   accomplish this proxy. However, this only works because I changed
   the user trust value on Joe's key. Until I do this, I will not be
   able to "truly" verify files signed by Susan unless I sign her
   key. But, because I now trust Joe (I changed the trust database
   when I did this), and Joe signed Susan's key, Susan's key pair changes to 
   '-/f'. Optionally, I could have signed her key which would have
   likewise changed it from -/q to -/f, but this wasn't necessary as
   previously explained. In this case, the trust database has been
   changed but *not* for Susan's key, only for Joe's. It now lists the
   owner trust value of '-f'.

I don't see that the trust database is a problem except possibly
allowing other users on your own system to read it. If you're worried
about that, then a `chmod` should suffice while still allowing you to
use it as required. As far as other, more remote users, are concerned,
they won't have access to the information contained in the database
even after receiving an exported key. The key itself SHOULD not
contain this information.

Let me know if this helps.

George sinclair | gsinclair@nodc.noaa.gov