Re: [Sks-devel] Re: Delete key from keyserver

[Anakin-Marc Zaeger]

That brings up a question (or rather, 2 questions, both connected).
What means would there be to prevent somebody from maliciously sending
a delete request for a particular key, and what would prevent somebody
from resubmitting, again, maliciously, a key which was deleted?  For
the first part, I'm thinking the request to delete could be signed by
the corresponding private key.  As for the second, the delete request
could be some sort of a "placeholder" which, upon a properly signed
request, could be removed, allowing the public key to be resubmitted.

On Tue, Sep 7, 2010 at 7:57 PM, Jeff Johnson <address@hidden> wrote:
>
> On Sep 7, 2010, at 10:46 PM, Robert J. Hansen wrote:
>
> On 9/7/2010 9:50 PM, Yaron Minsky wrote:
>
> I think that a basic form of deletion is pretty easy, and requires no real
> research  The algorithm is simple.  You simply add a new kind of pseudo-key
> to be gossiped around: a deletion token.  In the simplest version, the
> deletion token never expires; it's a permanent addition to the database.
> But the effect of adding the deletion token is that the thing it wants to
> delete is effectively removed.  With a small amount of extra cleverness, one
> can allow the deletion token to be removed eventually as well.  But given
> the small number of deletions that appear to be necessary, it hardly seems
> urgent.
>
> I see no reason to think the number of deletions will be small.  My
> nightmare scenario involves people with an interest in illegal information
> discovering the keyserver network makes a good vehicle for dissemination of
> relatively small pieces of illegal information.  All it takes is one person
> discovering this and others thinking it's a good idea and the next thing you
> know we've got keyservers drowned in spam.  It's just that this spam could
> get keyserver operators arrested for distribution of illegal information.
>
>
> Well yes but ... this is NOT an illegal piece of information until litigated
> afaik.
> And the pubkey was a previously legal piece of information or it never would
> have ended up on a SKS keyserver in the first place. Someone changed
> their mind and has a right to their privacy.
>
> (Note: although I see no reason to think the number of deletions will be
> small, there is also no reason to think my nightmare scenario will come to
> pass.  We simply do not know how many deletions will be necessary.  I think
> we ought keep this lack of knowledge in mind when we discuss solutions.)
>
>
> The number of deletions SHOULD be of the same order as the number of
> servers,
> modulo time lag from distribution latency, and servers entering/exiting from
> pools, etc.
> (aside)
> This assumes that only SKS servers need protection; there WILL be multiple
> occurences of the offending pubkey everywhere in keyrings, but that
> should NOT be the SKS keyserver operator's problem or risk.
> There are additional issues that WILL need to be thought through because
> -- once a mechanism exists to erase pubkeys -- that system MIGHT
> be abused in other ways.
> Or am I missing something essential here?
> 73 de Jeff
> _______________________________________________
> Sks-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/sks-devel
>
>