auto refresh-keys

[Micah Anderson]

I filed this today at https://bugs.g10code.com/gnupg/issue1235 but I
wanted to send it to the list to get wider discussion about the idea. 

If you do not regularly refresh your public keys from keyservers, you do not get
timely expiration updates or revocations, both of which are very important to
have available to your local keyring as soon as possible. If you do not refresh
your keys from the keyserver, and I have revoked my key because it has been
compromised, then you will continue to use my key without knowing that I've
revoked it. That can lead to bad situations. For proper functioning of a
distributed web of trust, this needs to happen, and until it does the breakages
in those links are too fragile and frequent.

I did an experiment recently where I set my key expiration to be short and then
one week before it was to expire, I extended the expiration and sent that to the
keyservers. What I found was that one week later, virtually everyone that I
communicate with using that key thought that my key had expired, because none of
them have a process to regularly refresh their keys in their keyring. I had to
contact them individually and explain the situation and then advise them to
setup a personal cronjob to do a regular refresh, typically I suggest something
like:

0 1 * * * /usr/bin/gpg --refresh-keys > /dev/null 2>&1

This is annoying for every gnupg user to have to setup on their own. It is also
problematic for people who do not understand cron. In my experience, asking
every user to do this is problematic, as very few actually end up doing it. I've
been begging people to setup cronjobs like this for the last 2 years as I've
been going through various key transitions, and very few of them actually do it,
even those that I have urged 3-4 times to do so.

It also cannot be done in a reasonable way automatically by distro packagers due
to the fact that package maintainers cannot know how the local admin needs to
have things setup (such as a system-wide cronjob, or a adduser hook). For
example, home directories are not necessarily local to a machine, and having a
system-wide cronjob to scan all user's home directories and then modify them is
not a good idea; or they don't use adduser and instead use automated tools for
account creation. 

It seems like the best solution would be to build into gnupg the functionality
that is similar to the automatic trust database operation: have gpg auto-refresh
From the configured keyserver periodically. There are some considerations that
should be made here, such as how frequent should this refresh operation happen?
Should it happen on every use, before the key is used? Should it happen just on
the key(s) that the current operation is going to act on? What about network
problems, such as no network at all, keyserver down, or slow? There should
probably be a low timeout to not cause user annoyance, but also some sort of
indication/warning that when a keyserver update could not be performed that the
key is potentially out of date. Users should have the capability to configure in
their gpg.conf a 'no-auto-refresh-keys' variable if they do not want this
functionality. Perhaps even some sanity checking on the data that is coming in
would be good to guard against gigabytes of data coming down.

micah
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: </pipermail/attachments/20100604/339d5f8c/attachment.pgp>