auto refresh-keys

[MFPA]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi


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
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:expires2010 at ymail.com

What's another word for synonym?
-----BEGIN PGP SIGNATURE-----

iQCVAwUBTBlAYqipC46tDG5pAQpUUAQAr1BehvzOnTbaximLahgfjluGm8ncBal8
1rSDj09uXLQaUO02uSeDmvPv5hSuZ4u5OCD2fRYvuGj7/Y2mki989gr0/gy9g8Ci
tUFsBDLVtF6nVBG9XydX3MD1q1veGcz/QdMm9ptEwokhsD3sHcVMLcwPDXcQpe2O
zTF8SYDnlOE=
=n0gp
-----END PGP SIGNATURE-----