[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pgp-keyserver-folk
Subject:    Re: delete/disable requests
From:       "teun, Tilburg University" <Teun.Nijssen () kub ! nl>
Date:       1999-06-30 9:04:42
[Download RAW message or body]

Hi,

Stefan wrote,

/In fact, about two weeks ago Teun Nijssen, Peter Wan, Hironobu Suzuki and I
/met in sunny Brisbane to discuss this issue. Basically, we agreed that we
/should find a mechanism (possibly based on the time a key was last touched
/and/or the time the most recent new signature has been added to a key) to
/delete very old keys from our database. Of course, the term "very old" has
/to be defined first. Anyway, right now there seem to be tens of thousands
/of keys that are surely no longer used. It is therefore a good idea to get
/rid of these keys (eg. to dump those keys in a special repository).
/
/We will probably come up with a more detailed proposal on this list once
/one of us found enough spare time to do so.

actually, I already took up the issue with the potential programmers, before
putting it on this list, were many people may have different opinions, but 
like me are not able to realize the code.

below you find a piece of the resulting discussion:

cheers,

teun
-----------------------------------------------------
From:           	Marc Horowitz <marc@mit.edu>
Subject:        	Re: No 0.9.4 Problems and the Brisbane BOF
Date sent:      	26 Jun 1999 16:23:47 -0400

"teun" <Teun.Nijssen@kub.nl> writes:

>> One of the items brought to the floor was about the unbounded growth
>> in the number of keys that are no longer actual. Almost all keyserver
>> managers have stopped disabling or removing keys because it is too
>> time consuming and keys do come back anyway.
>> 
>> So a thing we need, I think, is an automatic way to get rid of no
>> longer actual keys. As key expiration dates are hardly ever used, and
>> key age is NOT a good criterium, we need another mechanism. The
>> 'since' time indicating when the key hit a server is also not good, as
>> it differs between servers.
>> 
>> The best thing I could dream up is the LATEST SIGNATURE DATE.
>> 
>> Suppose you two brains can locate that latest signature date, a filter
>> in kd_add could refuse keys that were not signed or re-signed in the
>> last n days, say two or three years. A utility could each month go
>> through the keys database and delete keys that have gone stale by this
>> criterium.
>> 
>> If we want to complicate it a bit more, we can also decide that
>> revoked keys can stay longer or similar things. What do you think of
>> this?

The problem is certainly real.  I'm not crazy about this solution as
is, though.  I personally have keys which are still good as far as I
know (not compromized, and I have the private key), but which I have
superseded with new (longer) keys.  I haven't revoked the older keys,
because there's stuff out there I've signed with them, but I also
don't bother getting people to sign them anymore.

Your heuristic would make these keys disappear.

Perhaps it would make sense to modify the expiration based on the
number of signatures (maybe all sigs, or just ones whose keys are in
the database also) on the key.  Well-connected keys are both more
likely to be actively used, not just uploaded because someone played
with pgp once, and interesting for longer.  Keys with large numbers of
signatures also pretty rare, which means they don't contribute much to
the size of the database, so keeping them around isn't a big problem.

This heuristic can be defeated by people creating lots of bogus keys,
and signing their key with it, but there's lots of ways malicious
users can damage the system now.

I'd be curious to see a histogram of keys by number of signatures.

		Marc

------------------------------------------------------------------
yes, but; it would give the correct person, you, the chance to make them 
disappear or remain. Every two years you would only need to re-sign the key 
yourself to keep it in the servers. In this way your signature date would also
confirm that the key, old as it may be, is still usable.

/Perhaps it would make sense to modify the expiration based on the
/number of signatures (maybe all sigs, or just ones whose keys are in
/the database also) on the key.  Well-connected keys are both more
/likely to be actively used, not just uploaded because someone played
/with pgp once, and interesting for longer.  Keys with large numbers of
/signatures also pretty rare, which means they don't contribute much to
/the size of the database, so keeping them around isn't a big problem.

I'm afraid far to many keys are simply unsigned, except the self-signature.
Connectedness is not a cretirium, except that you don't really like to loose 
well-connected keys. But than again: as long as a key is regularly (re-
)signed, it will remain on the servers.

/This heuristic can be defeated by people creating lots of bogus keys,
/and signing their key with it, but there's lots of ways malicious
/users can damage the system now.

yep, right.

/I'd be curious to see a histogram of keys by number of signatures.

well, simply look at these numbers:

1999             Jan    Feb    Mar    Apr    May    Jun

New Keys       10006   8362   5941  14989  40259
New Sigs        1613   1702   1470   1216   3919

they show that once a key is on the server, it hardly ever gets a signature;
ten times as many keys arrive as additional signatues. (The signatures that 
are present when a key arrives initially are not counted in these figures; so
in 40259 new keys there will be 40000 self-signatures and 500 sigs by others
:-))

cheers,

teun

[prev in list] [next in list] [prev in thread] [next in thread]