I think that a basic form of deletion is pretty easy, and requires no real research The algorithm is simple. You simply add a new kind of pseudo-key to be gossiped around: a deletion token. In the simplest version, the deletion token never expires; it's a permanent addition to the database. But the effect of adding the deletion token is that the thing it wants to delete is effectively removed. With a small amount of extra cleverness, one can allow the deletion token to be removed eventually as well. But given the small number of deletions that appear to be necessary, it hardly seems urgent.
There is a policy question: who gets to add a deletion token to the system? The owner of the key to be deleted? Or perhaps there are a set of trusted administrators shared by the whole network who can ask for deletions? And, of course, there's the question of who is going to do the work. I don't have the time to devote to SKS at this point, so if this feature is to be added, someone else needs to do it. y On Tue, Sep 7, 2010 at 6:31 PM, Jeff Johnson <n3...@mac.com> wrote: > > On Jul 8, 2010, at 11:34 AM, Ari Trachtenberg wrote: > > > The backend data structure supporting SKS does not yet support true > deletion. > > We are researching this (but it will take some time :-) > > Now would be a _PERFECT_ time for some research to be actively deployed. > ;-) > > OTHERWISE > > Since their are only 50-100 (just a rough estimate) SKS servers, a key > could > most definitely be dropped with a modest amount of coordination. > > Consider what happens if the reconciliation protocol version is incremented > and 2 machines > deploy with the version++ protocol on a store that DROPS the offending key > and actively filters that key going forward. > > So there would be 2 SKS nets, and a need to coordinate a switchover from > one store to the other. > > Please note that I am NOT suggesting that the SKS protocol be incremented > (though that would most definitely "work"). > > What I am suggesting is that -- with a modest amount of coordination -- > there are solutions that could be devised in order to solve a "real world" > problem. > > This isn't the first person who decided to lititigate, and won't be the > last. > > JMHO, YMMV, I'm game for version++ (though I think there are most > definitely easier > ways to drop a pubkey than rev'ing the SKS reconciliation protocol version) > if anyone else > is. > > 73 de Jeff > > > -Ari > > > > On Jul 8, 2010, at 6:37 AM, Sebastien wrote: > > > >> Since I have no web interface running, I did this: > >> > >> #-- exporting the public key I want to drop in SKS database > >> gpg --export --armor --output mykey.asc -- myname > >> > >> #-- getting the MD5 hash of that key > >> md5sum mykey.asc > >> > >> then > >> > >> #-- dropping the key from SKS using MD5 hash previousy retreived > >> sks drop <mykey.asc_md5sum> > >> > >> Result: > >> > >> #-- key no longer exist in key server database > >> gpg --keyserver my_sks_server --seach-keys -- myname > >> > >> This could be fine... but I cannot add a new key anymore. Seems that SKS > >> database is corrupted now. Any idea ? > >> > >> > >> > >> _______________________________________________ > >> Sks-devel mailing list > >> Sks-devel@nongnu.org > >> http://lists.nongnu.org/mailman/listinfo/sks-devel > > > > > > _______________________________________________ > > Sks-devel mailing list > > Sks-devel@nongnu.org > > http://lists.nongnu.org/mailman/listinfo/sks-devel > > > _______________________________________________ > Sks-devel mailing list > Sks-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/sks-devel >
_______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
