As a quick and *dirty* implementation of key deletion I see two possibilities:
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. 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. 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. Kim Minh. _______________________________________________ Sks-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/sks-devel
