auto refresh-keys

[Daniel Kahn Gillmor]

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).

This is bad security for those users.  GnuPG should help those users to
Do The Right Thing as automatically as possible.

> 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?

here's a proposal: gpg could keep track of the last time it refreshed
any given key from a public keyserver.  when the user tries to use that
key, if the last-refreshed time is more than X days ago, the key is
refreshed (and the associated part of the trustdb updated?) before use.
 Upon succes, the last-refreshed time associated with that key should be
updated.

> 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.

Network or keyserver failures during an auto-refresh should be accepted
and the rest of the operation should continue (though the last-refreshed
time shouldn't be updated).

What if the network and keyserver are both available, but the keyserver
has never heard of the key in question?

> Users should have the capability to configure in
> their gpg.conf a 'no-auto-refresh-keys' variable if they do not want this
> functionality.

Sounds good to me.  i could even imagine this being a per-key setting,
but that might be more complexity cost than is worth incurring for the
(minimal) gain.

> Perhaps even some sanity checking on the data that is coming in
> would be good to guard against gigabytes of data coming down.

for signature data coming from keyservers during an auto-refresh, i
could see doing the following triage to avoid storing gigabytes of
unnecessary stuff:

 * discard all certifications made by keys which we do not have a local
copy of (since they are meaningless for computing calculated validity of
a key).

 * discard all certifications which are not cryptographically valid, or
are executed with cryptographic algorithms we do not support, or which
rely on known-weak cryptographic algorithms.

 * discard all certifications which are larger than some

Certifications fetched are either over:

 0) a User ID and a primary Key, or
 1) a primary key and an associated subkey (these are usually self-sigs
or revocations), or
 2) a primary key itself (also usually self-sigs or revocations)

For each thing being certified:

 * for cryptographically-valid certifications (or revocations) from any
given public key (or its associated subkeys): only store the
certifications with the most-recent certification date.  This prevents
fetching, say, 1000 certifications from an abusive certifier.

What do other folks think about this?  The more we can make gpg do the
right thing automatically (and this includes picking up revocations and
updates), the more useful it will be in terms of providing real secured
communications for its users.

	--dkg

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