Fw: [Sks-devel] keyserver.pramberger.at terminating
--Original Message-- To: pks-ad...@pramberger.at To: sks-devel@nongnu.org Subject: Re: [Sks-devel] keyserver.pramberger.at terminating Sent: 8 Sep 2010 21:45 We could probably learn from the tld registrars (for access to zone files) and set this up as sftp/ftp access with login tokens and access logs. In the long run some kind of contract to get these dumps could possibly also be discussed in order to insulate the dump provider from liabilities. --Original Message-- From: Peter Pramberger Sender: sks-devel-bounces+reg-sks=kfwebs@nongnu.org To: sks-devel@nongnu.org ReplyTo: pks-ad...@pramberger.at Subject: Re: [Sks-devel] keyserver.pramberger.at terminating Sent: 8 Sep 2010 21:32 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gabor Kiss schrieb am 08.09.2010 06:58: >>http://keyserver.pramberger.at(/network/) >>http://www.pramberger.at/peter/services/keyserver/(network/) >>ftp://ftp.pramberger.at/services/keyserver/keydump/ >>mailto:pgp-public-k...@pramberger.at > > How could we help? > Can we run some of the above services on our servers? Well, if someone will afford the resources for a public keydump or maybe a monitoring page, I can provide you with scripts (though they would need some work). If interested, please contact me off-list. BTW, because I mentioned public keydumps: I'm not sure whether this was discussed ever, but I'm still wondering if it is a good idea to provide entire keydumps for the public (without any control about who gets them), or if they should just be provided on request. Sure, there is no guarantee that someone requesting a dump (maybe on the mailing list) will really build up a keyserver, but at least it has to be requested... Any opinions? Br, Peter -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyH5NkACgkQcKsx5K5ighwMTgCfb9gl+dNNiuZIrN70jyUgOEuj easAn0R69hHQPbNW3kWI+QDG0//qtRld =KGWr -END PGP SIGNATURE- ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel Sent from my BlackBerry® wireless device___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Fw: [Sks-devel] keyserver.pramberger.at terminating
I've also been thinking along the lines of, in particular your solution #1, but maybe there is no need to alter the recon process at all. What we could do is adding another control stream besides recon - that distribute a set of delete instructions using some algorithm to get full sets. These instructions could, themselves, be digitally signed by the trusted introducer. Upon new entries in the sync process of this setup, the server would verify the signature, and upon valid signature 1) add the hash/keyid/fpr to the local blacklist for the recon 2) run a 'drop' mechanism. This way the delete/blacklist is a parralell process that is easier to control. Kristian Fiskerstrand --Original Message-- From: Kim Minh Kaplan Sender: sks-devel-bounces+reg-sks=kfwebs@nongnu.org To: sks-devel@nongnu.org Subject: Re: [Sks-devel] keyserver.pramberger.at terminating Sent: 8 Sep 2010 19:09 As a quick and *dirty* implementation of key deletion I see two possibilities: 1. One way would be to add a blacklist file of keyids that the server will refuse to add to its own database. This would probably have to be complemented with a blacklist of fingerprints dynamically maintained by the recon process to avoid repeated exchange of the blacklisted keys. 2. Another way would be to use a blacklist file of keyids to censor only the retrival process of the key. That is although the key is still in the database, the server will refuse to disclose its content. Compared to proper deletion of keys from the SKS network these mecanism enable each server admin to abide by his own policy. They also have their cons: solution 1 could lead to some form of partitioning of the network. Also peers will know which key is being blacklisted through the recon protocol. Solution 2 could be one step short of fullfilling legal obligations as the data is still in the database. Kim Minh. ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel Sent from my BlackBerry® wireless device___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
