Re: [Sks-devel] About deleting keys

[Arnold]

On 10/29/2013 11:40 AM, Kiss Gabor (Bitman) wrote:
> Several times in the past years the problem of deleting keys
> on user request is discussed.
> ...
> The fundamental problem was that some users want their keys to delete
> from _all_ key servers.

What users _want_ is not very relevant (well, sort of...) but more what they
legally can enforce you to do. They can (threaten to) enforce specific key 
server
operators to remove a key from their key server (not from the network).


> As we have seen already this is not possible for technology reasons.
> 
> If key removal is useful or desirable is a totally different question.

Agreed, with the legal threat the free open key server service we provide is at 
stake.


> Some guys argue against it saying it would make impossible to
> check digital signatures made by the deleted key.
> I reply: who cares? The situation is the same if the user never
> upload his/her public key to a key server.

Also the same if there are no key servers at all (all threatened and out of 
business).


> The problem is have to solve -- I think -- that users threaten
> key server operators with legal actions.
> 
> I have a proposal that may a trade-off. IMHO most of the complaining users
> will accept that their keys remains in the database but they
> are not appear in search results.

Providing less technical detail to those users is better ;-)

Why tell it remains in the database, just agree to 'make it unavailable from 
your
specific key server'. From what I know from our national law on privacy, 
operating
a key server is OK, but... if a judge decides otherwise, keeping it in the 
database
won't be acceptable either.

Therefore, I agree to have an easy to implement solution (for the key server
operator) that a) makes it possible to react on requests instantly (before legal
threats and lawyers etc.), and as a consequence b) keeps a key server in 
business.


> Technical implementation is the following:
> If a user wants to hide his/her key (s)he just have to add a special
> uid e.g. "Do not include in search results" or so.

If I remember right, there was a situation that Alice created a key with the 
name
of Bob. Bob complained to the key server operator, but he is not able to modify 
the
key Alice created. So, the key server operator should be the one who disables
retrieval of the key.

A technical solution I think of is to limit the search engine based on a list of
(primary) key ID's (full fingerprint). That list is a local configuration file.

For the key server network to function, I guess it is still necessary to provide
the key based on key hash.

Currently it is possible to show the key hash in the search results of the web
interface. I think it would be wise to hide that hash as well. Otherwise, Bob 
can
still argue that the key server operator still provides his key. And Bob would 
be
right IMO.

Does showing the hash serve any practical use? If it is only useful to SKS
developers and/or operators for testing and debugging purposes, it might be an 
idea
to make the hash only available via a debug option that is normally disabled.


> The search engine just should ignore these keys.
> 
> However key could be retrieved by hex keyID that makes

That won't help a key server operator who was legally forced not to provide the 
key
of Bob any more.

> ...
> Yes. Very smart and desperate end users and their lawyers may
> point out that the key is actually NOT deleted, and an impostor

If we don't tell... ;-)
Only people digging into this mailing list and people reading the source code 
may know.

But *if* a lawyer knows, I guess he will go for it (he is paid by the hour). It 
is
not their concern if you have no other option than to stop the service at all.


> BTW. The dumper could also drop these keys. Also the recon process.
> Or does this consume too much resources?

I also once played with the thought to only store the hash and key fingerprint 
in
the database to satisfy database equality. But, once you update the hash from
server A, then server B (not peering with A and then with an outdated hash), 
will
keep requesting the key associated with the new hash that you cannot provide. 
This
will continue, unless server B also replaces the outdated key with the new hash
only, effectively also deleting the key which we concluded before is 
undesirable...

Just my €0,02 as I am no SKS developer.

Arnold