auto refresh-keys

[Hauke Laging]

Am Donnerstag 17 Juni 2010 21:23:40 schrieb MFPA:

> > 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.

My aim was not to prevent the first unnecessary download but the others. 
Download it once from every keyserver and store the timestamp for every 
server.

Something I forgot: The keyserver should not update the timestamp for a key 
just because of a new upload. The timestamp should be modified only if the key 
is modified somehow.


> 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?

As I was talking about a keyserver feature I just don't care about non-
keyserver scenarios. In general it might be possible to create similar 
optimizations for other transport (application) protocols.

If it's an http URL then gpg might store the etag or timestamp and use If-
None-Match or If-Modified-Since in the request. But isn't this a rather exotic 
case? How many keys are configured that way? Are their owners to be freed from 
unnecessary traffic...?

I would advise to care about the keyservers first.


> > 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.

If your keyservers don't support TLS (I have no idea whether the important 
ones use it) then you are open to a MitM attack when checking them. If the 
response is signed then you are not (if you are sure about the signing key 
:-) ).

One more advantage: The signed response could be distributed among several 
systems of the same user or several users with similar keyrings. This would 
result in omitted or smaller requests (containing just those IDs not covered 
by the response). Several users might even combine their ID wishlist so that 
only one of them has to ask the keyserver.


> > 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?

MitM again. If you upload a changed key you cannot be sure (without TLS) 
whether it has arrived at the keyserver or just at one of the bad guys.


> > 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.

Right. So the keyserver would use the timestamp of the latest change at it


> 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.

Look at it the other way round: The more keys there are in the keyring the 
more bandwith is saved. I am convinced that users with large keyrings have 
enough local storage for that...


Hauke
-- 
PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 555 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20100617/f89121f8/attachment-0001.pgp>