expires2010 at ymail.com
Wed Jun 16 23:21:23 CEST 2010
-----BEGIN PGP SIGNED MESSAGE-----
On Wednesday 16 June 2010 at 6:10:17 PM, in
<mid:4C190579.40900 at fifthhorseman.net>, Daniel Kahn Gillmor wrote:
> On 06/16/2010 01:03 PM, MFPA wrote:
>> 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"
So, discard all certifications made by keys not on the server, all but
the latest certification from each key, unknown/weak algos etc, as per
your earlier message in this thread.
I'm having difficult deciding why this would still be all that useful,
when it has to be informed by which keys the keyserver recognises
rather than which are recognised by the user.
> 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.
This seems to me the most appropriate "fetch" for an auto-refresh
function, as well as good for use where storage and/or bandwidth are
> 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
Even if the mechanism doing the checking did support UATs, there are
enough keys around with (for example) inappropriately large images to
make this a valuable option where storage/bandwidth are under pressure
or where data transfer is metered and expensive...
> 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.
Would the certifications all be analysed by the server "on the fly"
before returning the requested key? If so, what are the likely
implications for increased server workload and fetch request
Maybe the analysis would sit better at the point of uploading the key?
1. the key is uploaded to the server.
2. the server analyses the key and generates the alternative
versions (minimal, reduced, no-UATs etc)
3. the several versions are hosted, and the form of the fetch
request determines which version is served.
4. there may be some merit in periodically re-analysing the
certifications on stored keys to refresh the modified versions,
eg the reduced version may change due to keys being uploaded to
the server that have already certified that key.
What happens if the fetch request for something other than the full
version comes after (1) but before (2) is completed? Is it best to
return the full version in that event (perhaps subject to a cut-off
Should (2) be completed as soon as (1) or added to a queue to be
processed periodically in batches?
When the server receives a new or updated key through synchronising
with another server, should the modified key versions be passed along
as well? If so, should the receiving server use these just in the
interim until it has calculated its own modified versions?
MFPA mailto:expires2010 at ymail.com
What's another word for synonym?
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
More information about the Gnupg-users