Re: [Sks-devel] keyserver.pramberger.at terminating

[Jeff Johnson]

On Sep 8, 2010, at 1:09 PM, Kim Minh Kaplan wrote:

> As a quick and *dirty* implementation of key deletion I see two possibilities:
> 

Nothing wrong with blacklists (or quick and *dirty* for that matter,
Peter's issue is rather important but has almost vanishing incidence,
*dirty* would be fine if legally acceptable).

> 1. One way would be to add a blacklist file of keyids that the server
> will refuse to add to its own database.  This would probably have to
> be complemented with a blacklist of fingerprints dynamically
> maintained by the recon process to avoid repeated exchange of the
> blacklisted keys.
> 

The issue here is likely that there are actually two blacklists needed,
one for each of the gossiping peers.

WHile you can likely filter the sender's polynomial pretty easily,
that is not true when receiving, becuae you MUST pay the transport
cost of additional keys that WILL be filtered by the receiver's blacklist.

That "cost" might be modest if just additional roots in an interpolating 
polynomial
(but there would be a computational cost).

> 2. Another way would be to use a blacklist file of keyids to censor
> only the retrival process of the key. That is although the key is
> still in the database, the server will refuse to disclose its content.
> 

Both of the above sort of assume a coordinated/distributed blacklist
amongst servers. And assumes that its the SKS network, not the
litagious luser, who is "responsible" for filtering.

With the "anonymous self-revocation" there's no need for blacklists
and the litagious luser gets to do the chores.

OTOH, there WOULD be costs associted with special handling for
a "pseudo-key deletion token" special processing somewhere. I
dunno OCAML well enough to estimate that cost.

> Compared to proper deletion of keys from the SKS network these
> mecanism enable each server admin to abide by his own policy.  They
> also have their cons: solution 1 could lead to some form of
> partitioning of the network.  Also peers will know which key is being
> blacklisted through the recon protocol.  Solution 2 could be one step
> short of fullfilling legal obligations as the data is still in the
> database.
> 

I think large parts of the different approaches have to do with how
one answers these questions:

        1) What is legally acceptable (as in responsibly dealing with the law)?
        Is deletion by anonymizing viable or is something else needed?

        2) Is this a SKS network store issue or is it a general issue?
        Note that no matter how deletion is achieved in a SKS network,
        there WILL be copies of the offending key stored everywhere
        in ~/.gnupg/pubring.gpg that (possibly) came from SKS keyservers.
        Is that a concern? Damfino: IANAL.

Again, nothing wrong with blacklists at all.

73 de Jeff