Let's think about a simpler question: deletion. Can SKS support outright deletion of keys? I think a fundamental question is one of trust: is there a trusted set of people who could do the deletions? If so, then one could pretty easily add the notion of a deletion certificate that could be gossiped around like a key, and would essentially eat some set of keys, causing them to be deleted from the database.
The problem is, I don't know that such a universally trusted set exists. So, what do we do? We could imagine having people volunteer to manage sets of banned keys. You could subscribe to a banned key service, and just always reject any banned keys from your store. The question then is, what happens during reconciliation? Maybe at reconciliation time, everyone just pretends to have all of the banned keys in their store, and so no one ever detects a difference based on banned keys. I haven't really thought much about the literature in this area for a few years. If real progress is to be made here, someone has to think carefully about what would be an effective protocol. To think about SKS, you don't really have to know anything about the fancy math behind reconciliation. Just think of it this way: you need to represent your knowledge as a set, and SKS gives you a cheap way to discover the symmetric difference of your set and someone else's set, and then you can synchronize based on that knowledge. Deletion certificates just act as another thing in the set, and so everything works pretty straightforwardly from there. If you want to design a better SKS, you should think about whether you can build the semantics you want on top of this basic set-based model. That said, another completely honorable, and in some ways simpler, approach, would be to give up on SKS' clever synchronization, and go back to a model closer to the old PKS one: do some kind of mostly-reliable broadcast. This would allow individual keyserver maintainers to freely delete whatever they wanted. Replication won't be perfect in such a world, but at least figuring out how to delete keys in this world requires no new ideas. y On Tue, May 19, 2015 at 4:50 PM Robert J. Hansen <r...@sixdemonbag.org> wrote: > > Even if we did have a better understanding of the filter code, the > > difficulty with phasing in filters like this (as you've noticed in > > your description) is that either the whole pool opts in, or the > > filter doesn't work. Peers with different filtersets cannot gossip > > with each other, aiui. > > This is my understanding as well, and if I recall some past > conversations with John Clizbe correctly, he shares in this. However, > before we bet the farm I think we should see what Yaron thinks -- maybe > he has an idea for a next-generation SKS that would permit this. I > don't know how it would be done, but then again, I'm not Yaron. :) > > > So if we're going to introduce new filters, we are going to cause a > > major disruption with the existing SKS network. While such a > > disruption may be warranted, it is probably not something we want to > > do twice, so we should roll all the desired filter changes into one > > massive disruption. > > Something seems to be handwaved here. This seems to be about the same > level of effort as moving the keyserver to an entirely new protocol. > (In effect, it would be.) So perhaps we should first ask, "can we do > better than SKS?" > > If we're going to go down this route I think we should start by looking > at academic research and seeing if there's some new idea that could > possibly be used to resolve some of SKS's problems. > > I completely agree that we only want to do this once. For that reason, > I think it would be prudent to give serious thought to whether there was > something better than SKS to switch over to. > > My impression is there is not, but I haven't done an in-depth search, > either. > > > So the questions i have for a proposal like this: > > I think limiting this discussion to just filters is a little premature. > If we decide that SKS is the best thing going and we need to keep it, > then yes, some sort of filter set seems appropriate. But see above > regarding keeping our eyes open to other options. > > _______________________________________________ > Sks-devel mailing list > Sks-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/sks-devel >
_______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
