-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi
On Wednesday 16 June 2010 at 8:26:11 PM, in <mid:201006162126.17550.mailinglis...@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:expires2...@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----- _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
