auto refresh-keys

[David Shaw]

On Jun 14, 2010, at 12:50 PM, Daniel Kahn Gillmor wrote:

> On 06/04/2010 01:35 PM, Micah Anderson wrote:
>> 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.
> 
> I think something like this would be a good idea.  I've found that many
> users (even sophisticated users) of GnuPG never refresh their keyrings
> manually, which means that they use a good strong tool to (for example)
> encrypt messages to known-revoked keys (in a recent case, to a key whose
> revocation certificate was published over 2½ years ago).

When I wrote the new keyserver stuff, I thought about this sort of thing, but the lack of a good way to store metadata was a problem (the keybox fixes this), as well as the concern that keyservers are effective trackers of who is using what key.  For example, a keyserver operator could tell (based on how often which keys were refreshed), who your encrypted correspondents were, in rough frequency-of-communication order, to boot.

This doesn't necessarily make it a bad idea, of course - for some people, the benefits outweigh the disadvantages. It should be something users would have to elect to turn on, rather than having it turned on by default, though.

I'd want to hear from the keyserver community about this.  It's easy to talk about improving behavior, but they're running a free public service out of the kindness of their hearts.  This client-side change could mean a rather significant increase in the amount of bandwidth their free service consumes.  Some other useful client-side optimizations require the keyservers to actually do crypto (rather than be the easier packet stores), which requires a pretty dramatic change in the keyservers themselves.

David