-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi
On Wednesday 16 June 2010 at 6:10:17 PM, in <mid:4c190579.40...@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 limited. > 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. 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 processing times? Maybe the analysis would sit better at the point of uploading the key? I mean:- 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 size)? 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? - -- Best regards MFPA mailto:expires2...@ymail.com What's another word for synonym? -----BEGIN PGP SIGNATURE----- iQCVAwUBTBlAYqipC46tDG5pAQpUUAQAr1BehvzOnTbaximLahgfjluGm8ncBal8 1rSDj09uXLQaUO02uSeDmvPv5hSuZ4u5OCD2fRYvuGj7/Y2mki989gr0/gy9g8Ci tUFsBDLVtF6nVBG9XydX3MD1q1veGcz/QdMm9ptEwokhsD3sHcVMLcwPDXcQpe2O zTF8SYDnlOE= =n0gp -----END PGP SIGNATURE----- _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
