sks-devel
[Top][All Lists]
Advanced

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

Re: [Sks-devel] About deleting keys


From: Petru Ghita
Subject: Re: [Sks-devel] About deleting keys
Date: Fri, 08 Nov 2013 04:18:31 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0

On 11/08/2013 12:21 AM, Arnold wrote:
> However, I can think of situations that I definitely will have a problem.
> Therefore, I welcome the possibility to delete (or at least hide) specific 
> data,
> without the need to stop the service completely (_if_ the situation occurs).

> I just hope the ones who are fine without the possibility to delete or hide 
> data
> support the ones who feel the need to have it. We can then start the 
> discussion
> what needs to be done.

> Currently we still seem to be in the state of debate whether it is valid or 
> not
> that some feel they might need to delete or hide keys.

I do agree that theoretically it would be nice to be able to remove
unwanted data.

What I propose is that we should discuss is the who would be allowed to
delete the data.

As I see it, there are two possibilities here:

1) We don't make any further assumptions about the data ownership and
create some kind of group that is allowed to perform the deletion.

One possible compromise here might be a rule such as: if the key was
first posted on your server you as the server operator are responsible
for it. It would of course need some more work, because a server may
temporary or permanently go offline in which case the responsible person
should be re-nominated, etc. But at least you'd have someone appointed
responsible that would be able to perform removal operations.

In this scenario the rest SKS operators would be operating in a similar
fashion to a non authoritative DNS server for the data that was
initially posted on someone's else server.


2) We give the user the ownership of the data stored into the server.

The second method is what I'd vote for if asked but this would imply
some kind of authentication and authorization mechanism, possibly
something like the PGP Global Directory mentioned earlier.

Please note that even with this approach your identification parameters
would be an email address and a private key. Once you'd lose access to
any of these, you as a user would not be able to perform key modifications.

Key server administrators would still be able to perform those. Because
we know from what email address an offensive UID was created we could
ban it. This would be the main argument against option 1 above.

All this remembers me something similar to ICANN but for pgp keys and I
think that we would probably end up charging users a fee for keeping and
distributing their public keys. Leaving aside all other considerations,
charging a fee, would mean that the user would forcefully disclose some
personal information about their identities to us.

Kind regards,
Petru

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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