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

[Alexander B. Schmidt]

Just another suggestion:

What If sks would delete the public key itself, but keep the hashes of
deleted keys. Then sks-servers could reject uploads from keys with
hashes already in its "deleted-keys-database" and still the full deleted
public keys aren't known by the sks network anymore.
In principle two different keys could have the same hash.(?) - But I'd
say the probability is quite small and neglectable. (?)

Regards,
Alex.

On Wed, 2010-09-08 at 14:15 +0200, Johan van Selst wrote:
> Yaron Minsky wrote:
> > I think it would be a mistake to implement deletion in the way I described
> > without some notion of trusted introducers.  And that should I think be
> > implemented by having a set of keys that the full network trusts to
> > introduce deletions.  As I said, there is real work getting the code to make
> > this happen, and also doing the social work of choosing the trusted sources.
> 
> I don't think it is hard to come up with a couple of names from the
> community of people who can be trusted to do this job. But I'm not sure
> that we should push forward with this.
> 
> With the power also comes responsibility and a (legal) liability. These
> people may be considered accountable (by others) for anything that goes
> on in the SKS network. Users mentioning a brand name in a comment field,
> an offensive picture with the key, or whatever, just complain to the
> 'moderators'. To avoid legal claims, and fight battles they cannot
> afford to fight (even if winning might be guaranteed), these chosen few
> may have to approve a lot of undesired deletion requests, once word gets
> out that they can do this.
> 
> Being responsible for a large international data network, is quite
> something different than being responsible for a single local server
> within a clear jurisdiction and some small control over who can access it
> (even if it is very rudimentary with a couple of system firewall rules).
> 
> 
> Ciao,
> Johan
> 
> P.S. Yes, I'm probably imagining issues and risks that may never occur.
> But we should consider potential future problems and step carefully.
> 
> _______________________________________________
> Sks-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc
Description: This is a digitally signed message part