auto refresh-keys

[MFPA]

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

Hi


On Wednesday 16 June 2010 at 8:26:11 PM, in
<mid:201006162126.17550.mailinglisten at hauke-laging.de>, Hauke Laging
wrote:


> Am Mittwoch 16 Juni 2010 19:10:17 schrieb Daniel Kahn
> Gillmor:

>> Do you have other suggestions?  We should consider
>> bringing a prioritized form of these to the sks-devel
>> list.

> A different approach might save even more bandwidth:
> Most keys do now change often. It is useless to
> download a key that has not changed.

A key may be sitting on a non-synchronising server that has not been
modified at all recently but contains certifications not on my local
copy. The key has not changed but contains information not in my copy.
Downloading it is not useless.



> Thus the client could send a list of all keys it wants
> to check and the server could respond with a list of
> fingerprints and modification timestamps.

In the case of a key flagged with a preferred keyserver-URL, the
"keyserver-url" may just point to a key file. Does the client just
receive the file, or can it see the last modification date and
terminate the connection without downloading the file?



> If the server wants to do its job (without TLS)
> especially well then it signs this list and solves a
> today unsolved problem by that.

Please expand.



> This way you could even
> check whether a key update of yourself has reached a
> (non-TLS) key server.

Why/does the keyserver signing its list make a difference to that?



> It would have to be decided whether this key server
> time stamp refers to the newest time stamp of a
> signature in the respective key

This would be a security problem in the event that somebody uploads to
the servers a revocation certificate they had prepared in advance;
this revocation would be overlooked if the latest modification date of
the key were taken to be newest time stamp of a signature.



> (then the time stamp
> would be the same from all key servers and the client
> could check the local key to find out whether it has
> the current key)

Assuming all the servers the user ever checks against are
synchronised. Also assuming the certification to be uploaded most
recently to the servers always equates the one containing the latest
time-stamp.



> or to the timestamp of the last update
> on the key server (which would require the client to
> store the timestamp of the last key download for every
> key server).

If the client could reliably tell from the server's response that it
synchronised with a particular group-ID of keyservers, the client
would need only the timestamp for the last time that key was
downloaded from a member of that group. Probably easier to store the
info per synchronising group-ID than per individual keyserver, but
still a major undertaking if you are storing it for all the keys on a
large keyring. (Maybe the file of which servers synchronise with which
others should be a local file rather than relying on what the servers
tell you.)


- --
Best regards

MFPA                    mailto:expires2010 at ymail.com

Oven mitt: A partially charred grease stain that fits over the hand.
-----BEGIN PGP SIGNATURE-----

iQCVAwUBTBp2RKipC46tDG5pAQoq0AP/VkqhnPRzaPc8pzTCCSLFOnBi4PUGhuJf
sPZqTeyUzXAhhkmjx7kpqdU0wuIV7dXAGiJmyQIJfx8lK7Slgg0G7ZlDBVrboCOe
cBm/xnwOsKW2Tk6duZ5ojvzuQaUQ3g7SbarJVmhwGc0lJc5UeBxDdB63et+M9gBx
iYsnoKD6swk=
=/MYK
-----END PGP SIGNATURE-----