auto refresh-keys

[MFPA]

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

Hi


On Friday 18 June 2010 at 8:13:52 AM, in
<mid:201006180913.57817.mailinglisten at hauke-laging.de>, Hauke Laging
wrote:

> but this is about the share of file URLs in the keyring
> not the number of file URLs against the number of
> alternative key servers.

My guess would be maybe 1-2% of my keyring. I'm not about to examine
400+ keys to find out. Anyway, as I said before my keyring is too
small a sample to be statistically valid.



> Another point: With a good auto refresh infrastructure
> less people might feel the need to use such a file URL.

Maybe, but it also depends on people's reasons for trying to direct
people to the file URL that they control...



> You are missing the kind of attack. The WoT prevents
> you from being attacked by modified keys. It does not
> prevent you from being "attacked" by non-updated keys.
> The attacker can send you the file you already have.
> This is more a DoS attack with security implications
> for revoked and added keys and  organizational
> implications if you need more signatures to verify a
> key.

Hmm. I spotted the security issue of missed revocations if the
timestamp of the most recent signature was used to identify the last
update, but failed to see this. Maybe I should only reply when awake
and alert.



> Yes but it seems to me that none of that is equally
> convenient to simply passing the timestamp file to the
> other systems.

Convenience would depend on the users preferred ways of working, as
well as the hardware and software that make up his multiple systems.

Also, I had not thought of the list of timestamps as being a file
rather than just a reply in the dialogue between the client and the
keyserver.



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

> Yes. That would be kind of a caching proxy service.
> Privacy protection could be reached by taking "secret"
> IDs off the list for the "proxy guy". Unrevealed IDs
> would be checked directly.

If the secret IDs were hashes of the name and of the email address of
the creator, leaving them on the list would not compromise privacy
(other than maybe "associating" the user with that key, and thereby
with its creator...).

I consider a key UID that shows my name and especially my email
addresses to be an un-necessary erosion of privacy.



> If gpg was to be extended by
> an option to create an ID list I would suggest the
> feature to mark keys as not to be revealed by such
> update lists.

As we are talking about updating keys already on the keyring, I see no
need for the update list to contain any user-IDs, just the key_IDs or
fingerprints. Any un-necessary generation and transmission of
unencrypted lists containing names and/or email addresses is something
to be avoided.



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

> Sending to several keyservers does not help if the MitM
> attack point is on your side.

Even if you send the key over an encrypted connection to a server? For
example https://pgp.webtru.st/



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

> How large is your keyring file?

Nearly 6MB. But I'm not using it on a mobile device with tiny storage.



>  I assume that for ten
> checked keyservers the file for storing the last
> timestamp for each key and keyserver would not even
> have the size of the keyring.

That would probably be true, since most keys these days take up more
bytes than it would take to write the time and date ten times plus ten
keyserver URLs.



> And if there are only 40 KiB of space left on the
> device then IMHO you simply have to face the truth:
> That the wrong device it used for the application
> GnuPG.

If it's *that* small or full and can't be expanded or more space
cleared, you are probably right.

- --
Best regards

MFPA                    mailto:expires2010 at ymail.com

Why is the universe here? Well, where else would it be?
-----BEGIN PGP SIGNATURE-----

iQCVAwUBTByrvqipC46tDG5pAQo8SwP+NC0k9GyDUaAcsn7tBtAren2SskJID5ig
wGsx/yLsQyhjFhCQP4sgLc7lNwsIEy10mxXhIBzhgdVUIGcKUDze/aqld1Ze6m6F
JmGHkbHNttp4gHDR+cqzed+NzWu+lNndeWBp5whXxTdHH9Y+mhqTwt9o4FmrnXZ4
OfTUsEFcH+Y=
=L5+w
-----END PGP SIGNATURE-----