Re: [Sks-devel] About deleting keys

[Arnold]

On 10/29/2013 02:30 PM, Kristian Fiskerstrand wrote:
> The discussion gets even more interesting when dealing with revoked
> keys. If an attacker (with compromised secret key material) is given
> the ability to deleting such a key from the server network and
> re-uploading a non-revoked version; The effective security of the
> whole system is compromised (or for that matter mallicious key server
> operators doing the same).
> 
> There are good reasons for the servers being add-only by design... and
> you'll find several discussions on this in the past.

True, the SKS *network* should be add-only by design. However, this does not 
imply
that each key server is required to _provide_ each and every key in its 
database or
in the SKS network by means of a search.

If the SKS network (currently) can operate based on search by hash only (which I
assume) and if no current practical use (other than test or debug) is hindered 
by
hiding the hash from search results (disabling the option "hash=on"), then
filtering search results by means of a list of key fingerprints seems feasible 
to me.

There are several possibilities with filtering of search results (just brain 
storming):
1) simply provide no result as if the key does not exist
2) return a code/text that makes clear there were search results filtered out 
for
the specific search request
3) provide a list of all key fingerprints that the server actively filters out
(possibly using /pks/lookup?op=filtered or something like that)
4) return a redirect code to a random peer key server that might provide the key
(are redirects possible with HKP ?)

Option 3) seems desirable to me. Option 4) if possible at all, must be
configurable, as some judges think 'pointing to' is the same as 'providing', as 
we
see with the pirate bay.

For revoked keys that are configured to be filtered it might even be possible to
send the revoked key without any uid as a configurable option.

Arnold