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 <douglas...@protonmail.com> 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 > Sks-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/sks-devel > Lukas -- Lukas Martini https://lutoma.org Twitter: @lutoma Jabber: lut...@ohai.su If possible, please consider replying with PGP encryption.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
