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: Arnold
Subject: Re: [Sks-devel] About deleting keys
Date: Tue, 29 Oct 2013 23:48:23 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12

On 10/29/2013 11:25 PM, Kristian Fiskerstrand wrote:
> On 10/29/2013 11:05 PM, Arnold wrote:
>> I deliberately separate the two. First thing is the possibility to
>> hide / remove / whatever a key from a network of individual and
>> independent key servers (operating under different local laws). If
>> that is sorted out, we can discuss how to continue to provide the
>> additional services like the single DNS for the whole network and 
>> maintain our own lever of (internal) quality.
> 
>>> If there is fragmentation in the network we'd have to split the
>>> servers (probably exclude servers
> 
>> Excluding servers might not be scalable well as more countries
>> implement some kind of privacy law.
> 
> The pool only require one single load-balanced server in the front
> located in some country where such limitations doesn't apply to fulfil
> its goal, synchronizing with the other servers to get key updates
> (although that certainly would be a suboptimal solution with regards
> to latency (in particular network roundtrips)).

The scalability I was talking about was about the existence of multiple servers 
in
multiple countries (to have available for balancing the load for one thing). If 
we
don't take care of this thread, the SKS network might very well be reduced to a 
few
servers in a single country very soon... I am not looking forward to rely on SKS
key servers in some country where they log and analyse which keys I retrieve.

Therefore, I split the two: first implement something so operators of SKS key
servers can deal with local requests for deletion. Hiding may be phase one. It
might be necessary to follow up with a phase two: actual local database deletion
with some means in place to prevent resynchronising that key.

Arnold



reply via email to

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