Re: [Sks-devel] Verification of keys on upload and removal options

[Lukas Martini]

Hej,

I suppose the only feasible way is for each key server operator to be
able to specifiy a sort of custom block list of keys their server will
not accept/show/propagate.

Over time, some collaborative list curated by trusted operators would
probably emerge that most of the key servers would use.

That brings its own set of issues for the pool though. Like, if a server
in the pool went rogue and blocked a large number of keys, which might
compromise pool users' security. Then again, that is already possible on
a theoretical level.

Lukas

On 03/25/2016 02:33 PM, Andrew Gallagher wrote:
> On 25/03/16 13:16, Christoph Egger wrote:
>> Hi!
>>
>> Douglas <address@hidden> writes:
>>> It doesn't benefit anyone to retain keys uploaded with malicious
>>> intent, so I believe it's worth discussing a mechanism for key removal
>>> due to abuse of the system.
>>
>> Sure. I suggest you start  by reading the Minsky paper on how the
>> keyservers work and bring forward a feasible protocol proposal.
>>
>>   Christoph
> 
> Before we even *think* about a protocol, there are policy hurdles to be
> overcome, e.g.:
> 
> 1. What criteria should be met before a key is removed?
> 
> 2. Who decides that the criteria have been met?
> 
> 3. How are malicious removals prevented?
> 
> 4. How is whack-a-mole prevented?
> 
> These are all *hard* problems, and none of them have much, or anything,
> to do with protocol design.
> 
> A
> 
> 
> 
> _______________________________________________
> Sks-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/sks-devel
> 



    Lukas

-- 
Lukas Martini
https://lutoma.org
Twitter: @lutoma
Jabber: address@hidden

If possible, please consider replying with PGP encryption.

signature.asc
Description: OpenPGP digital signature