[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Fw: [Sks-devel] terminating

From: Kristian Fiskerstrand
Subject: Fw: [Sks-devel] terminating
Date: Wed, 8 Sep 2010 17:26:35 +0000

I've also been thinking along the lines of, in particular your solution #1, but 
maybe there is no need to alter the recon process at all. 

What we could do is adding another control stream besides recon - that 
distribute a set of delete instructions using some algorithm to get full sets.

These instructions could, themselves, be digitally signed by the trusted 
introducer. Upon new entries in the sync process of this setup, the server 
would verify the signature, and upon valid signature 1) add the hash/keyid/fpr 
to the local blacklist for the recon 2) run a 'drop' mechanism.

This way the delete/blacklist is a parralell process that is easier to control.

Kristian Fiskerstrand

------Original Message------
From: Kim Minh Kaplan
Sender: address@hidden
To: address@hidden
Subject: Re: [Sks-devel] terminating
Sent: 8 Sep 2010 19:09

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

Kim Minh.

Sks-devel mailing list

Sent from my BlackBerry® wireless device

reply via email to

[Prev in Thread] Current Thread [Next in Thread]