Re: [Sks-devel] About deleting keys

[Kristian Fiskerstrand]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 10/29/2013 11:05 PM, Arnold wrote:
> On 10/29/2013 03:51 PM, Kristian Fiskerstrand wrote:
>> 
>> 
>> On 10/29/2013 03:47 PM, Arnold wrote:

...

> 
> Good you mention the pool. From my point of view "the" or "a" SKS
> network is just a number of individual key servers running on
> individual hosts, operated by individual operators/administrators.
> The operators have little agreements with a few other operators to
> peer with each other and thus form a network. From this point of
> view our pool is just one SKS network. Multiple may exist in the
> world.

I agree on this point, I should have been more explicit in my original
email.

> 
> Our network provides additional services besides offering keys and
> synchronising among many servers. We provide a single 'server host
> name' (DNS) that resolves to multiple key servers with some kind of
> quality in terms of availability and completeness of the database.
> 
> 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.
> 
> Hope this explains my point.

Thanks for elaborating.

> 
>> 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)).

> 
> Just a thought, but this should really be step two. The DNS servers
> of the NTP-pool (http://www.pool.ntp.org) dynamically provide
> 'nearby' pool servers. We might do the opposite and provide 'far
> away' servers as it is unlikely those servers are forced to remove
> 'nearby' keys.
> 

See my comment above, that would make this step moot :)

> 
>> with deleted keys).
> 
> My suggestion was not to delete a key, but merely to hide it in
> search results (to the highest degree possible). That highest
> degree possible is IMO a must to prevent lawyers actually demanding
> (and legally enforcing) deletion of the database.
> 


- -- 
- ----------------------------
Kristian Fiskerstrand
Blog: http://blog.sumptuouscapital.com
Twitter: @krifisk
- ----------------------------
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- ----------------------------
Bene diagnoscitur, bene curatur
Something that is well diagnosed can be cured well
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.1.0-beta255 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJScDXSAAoJEAt/i2Dj7frjMCIP+wQkssNZ1xZCDUpvc+HeqG+V
XpRdeCxGmJI8TgBQRhFMQL1c4Cdxm6rUoUAtLsBz0NNm0G7CYWUJoyvQcMbUIT94
qYOdPV/Y3SBE3mHiaMq4eqESQ453bknwMV+t8/A1KwtgQara9GJ4KN3GAobWBTzM
nyIjq0RTZzkbe40onyFC76Oz9Zpo7eb7v4caTXiY70uDWLrrPqYKJtUq6RQipGWO
w+NWwp67HozNuFSRKt3+OYRfFs88mRjvvML+Ew3ZaRwy4gv6wEI0nb8DUkhfkHbM
s9kUn3NZ1fTcY+OF19wwc2z5iEiXs2wdTFQLaKTySSSoIIcfOElpJVDe87DLL2Jy
3Z2otgosbTPHuaqutoNe4yzDSnraXDoTv+6NRBTh6xO4BDwKb+SM3hvmOFGEAzJh
qNHd/N0NOm48oBrAXfEKCLBlfVUVhKqW+fHD497srk20tPi2oj2lAhzH8M31sa7U
DQQ9++ip/E2LzNJoRQ/Gbjj7YD4wMBf4Cw0WhGYJSNgZ/V0S0IVskl8jHS5xi0KA
DF2fXyOQXZzEXw0B/FzhyRctMktyhD9N+g6qOhnv6mUZXWH5y1um127hMRVhI4X8
vsyJMIcHNwNwfFoLG5bYIImXb8bHmvA1OyBeiKYKpnf3MONkBCUno764+yIqsAkW
3D6midNbmx4H0zNpbbaO
=9nsU
-----END PGP SIGNATURE-----