auto refresh-keys

[MFPA]

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

Hi


On Thursday 17 June 2010 at 9:14:55 PM, in
<mid:201006172215.01214.mailinglisten at hauke-laging.de>, Hauke Laging
wrote:


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

I was only trying to point out that it might not be useless to
download a key that hasn't changed.



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

I'd presumed that, but it is worth stating.



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

I don't know how common or uncommon it might be. I just know that, of
the keys in my keyring of about 400 keys, I have noticed more
deviations away from my default keyserver to key.asc files than to
alternate keyservers. I don't spend a lot of time watching the screen
when I refresh all keys, so my observation is not in the least
scientific. And even if it was, my sample size would be orders of
magnatude too small. (-;


> Are their owners
> to be freed from unnecessary traffic...?

> I would advise to care about the keyservers first.

I was actually caring about the user who is refreshing the key; it
would be good to avoid un-necessary data transfer/processing/storage
whether the key is on a keyserver, hosted on the creater's website or
on BigLumber. Since the bulk of key downloads are probably from
servers, that is the first place to look for efficiencies in this
respect. But the other scenarios and hosting/download platforms merit
consideration from the start.



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

OK, up to a point. But the web of trust should thwart this MitM
attack. Or am I missing something?



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

A user with several systems could use common keyrings. Or his own
local keyserver. Or just export all keys from the keyring he has just
updated and import them into each of his other keyrings. (I'm
guessing/hoping the new keybox format allows identification of all
keys modified since a particular time/date, so that just those could
be exported/imported when doing that.)



>  Several users might
> even combine their ID wishlist so that only one of them
> has to ask the keyserver.

Possibly in a corporate or group setting, where one person could
refresh the keyring and push the update to his colleagues?



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

I guess there is a risk if the change was a revocation because the key
has been compromised, and it only reached the bad guy but not the real
keyserver, and you had only tried to send it to that one server.



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

And if they are using a mobile device with limited storage they
probably aren't using a large keyring?



- --
Best regards

MFPA                    mailto:expires2010 at ymail.com

Don't ask me, I'm making this up as I go!
-----BEGIN PGP SIGNATURE-----

iQCVAwUBTBq5d6ipC46tDG5pAQp16gP9FrnuEfUQKYzKGr79BoWU5raWWG7LvMBq
Jtk/RZOMmy6u9K/2WcbfCHZ3y2QpyXwqibj3bOI9nXnDDFlOxceqG+N7wXZJn8U1
jmAVCZVKcdIEqaoaotQNgSY2SPW7Oq2Xfcibhs6V1Iitw5BsyaqCn9YxHHbIGlQr
wicXiXWPqtI=
=5T6Z
-----END PGP SIGNATURE-----