auto refresh-keys

[Daniel Kahn Gillmor]

On 06/16/2010 01:03 PM, MFPA wrote:
>> Plus, if we can demonstrate that GnuPG cares about
>> minimizing costs to the user in terms of disk space, we
>> also stand in a better rhetorical position to encourage
>> development (or adoption) of alternate keyserver fetch
>> requests that could apply similar minimization
>> heuristics to bandwidth.
> 
> What sort of alternate fetch requests do you envision? Fetch-minimal?
> Fetch-no-photos?

I was considering the same heuristics that i outlined here (though
they'd be relative to the keys that they *keyserver* knows about, rather
than the keys that the user knows about, of course).  This would be a
species of "fetch-reduced"

Your "fetch-minimal" would probably only fetch the latest
cryptographically-valid self-certifications made by the key itself (or
its subkeys.  This would facilitate fetching revocations, expiration
updates, changes in algorithm preferences, etc.

a "no-UATs" flag (what i think you mean by "no-photos") might also be
useful in minimizing bandwidth if the mechanism doing the checking has
no way of dealing with UATs.

Do you have other suggestions?  We should consider bringing a
prioritized form of these to the sks-devel list.  Probably
"fetch-minimal" would have the best work-to-reward ratio, though it
would involve teaching SKS about how to compute the crypto.

	--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/20100616/ff63b313/attachment.pgp>