Re: [Sks-devel] About deleting keys

[Arnold]

On 11/04/2013 10:14 AM, Johan van Selst wrote:
> Petru Ghita wrote:
>> To sum it up:
>> - there is by architecture no intent on verifing nor identifying the
>> information stored on the SKS network nor the author of the data.
> 
> It doesn't matter if the information is verified. Users are asked for

Not only are they asked, they can provide whatever they like, possibly with the
intention to harm ones reputation or cause damage to a person in some way.

> their name and email address, which is considered personal data
> (according to EU definitions) and keyservers are processing and storing
> this data. Thereby, keyserver operators are subjected to the data
> protection laws. The validity of the data is not relevant, neither is
> the intention of the operators (commercial or otherwise).

I think (I am no lawyer) the law (in the Netherlands) aims at organisations, not
individual citizens (you can have a private address book). However, I don't 
want to
find out in court.

> If national or international data protection laws give users the right
> to have their personal data removed from servers, then it should be
> possible for local keyserver operators to comply with that law.
> Preferably without terminating their service.

I second that.

> The privacy and data protection regulations are not the only thing to
> worry about. If people put Nazi slogans or death threats into UID
> fields, or put child pornography into JPEG attachments, then there may
> be other laws that can force keyserver operators to remove keys.

True. As SKS operator I am responsible for the data on my system. The fact I
*choose* a software system (SKS) that is 'all or nothing' does not prevent a 
judge
from telling me to remove particular data. If that means I have to remove all 
data,
then that is my problem.

> IMHO there is a clear demand for the option to remove certain keys -
> or at least make them irretrievable locally. That some keyserver
> operators are asking for the feature, should be reason enough to move on
> to discussion of the technical aspects.

We have a few questions that needs to be answered before going to technical
solutions. These are some questions I can think of right now, please extend :-)

Q1) is it sufficient to hide data for users of our service, while we keep full 
key
data in our local database?

Q1.1) if we hide data for the users of our service, do we hide all (like the key
does not exist), do we strip uid's, but still return key material including key
expiration, revocation, etc.?

Q1.1.1) if we hide, but still provide some data, is it retrievable by key id 
only,
or also as search result on name or e-mail?

Q1.2) if we keep full key data in our database, are we allowed to actively send
that data (push or pull) to our SKS peers?

Q1.3) if we keep full key data in our database, do we allow that specific key 
to be
updated by users of our service (i.e. from GnuPG, web interface)?

Q2) if we remove data from our local database, do we remove all data of a key, 
or
do we just strip some data (at least all uid's)?

Q2.1) if we strip some data and keep some other, which data do we strip and 
which
do we keep?

Q2.2) If we keep some data in our local key server, but strip for example 
uid's, do
we still update that key with other data (like expiration date of the key or a
revoke certificate)?

Q2.3) If we remove some or all data of a key, do we inform our peers during
synchronisation?

Q2.3.1) what to do when we receive a 'delete indication' from a peer, do we 
want to
get a warning, do we want to delete the data also from our own server, do we 
want
to delete that data only if we receive it from a peer we have marked as 
'trusted'
in our membership file, something else?


Once we know what we want (ideally), the OCAML developers can see what is
technically feasible short term, long term, 'at all' and which things are
configurable (like only hiding, stripping uid's, totally removing a key, any mix
per key, etc.)

If the technical solution results in some servers providing data other servers 
do
not, then we will have a follow-up discussion about which servers to include in 
the
pool. But let's first get clear what we want as individual SKS operator.

Arnold

signature.asc
Description: OpenPGP digital signature