The problem with the second plan is that the potential number of differences between hosts could grow quite large, degrading performance.
The easiest solution would be to auto-expire keys after a fixed time (a good strategy anyway from a security perspective). Best, -Ari On May 30, 2012, at 7:55 PM, Yaron Minsky wrote: > Here's my quick sense of what the reasonable solutions are: > > - Add a key-deletion authority, as Gabor suggested. These deletion > certificates would be gossiped around, and would lead to deletion of keys. > The deletion certificates would stick around for a long time, but they'd > be small, so the cost would be low. One coud have them auto-expire at a > specified time out, so that you eventually can GC them. > - Have SKS have a local key-deletion file. Keys listed in the key > deletion file would be excluded from the local set, but would probably be > kept in the Ptree, so that they don't show up as a difference when > reconciling. People can work together to distribute key-deletion files > from a trusted source, but it's at the discretion of the manager of any > individual key server. > > The second one seems more likely to work as a social matter, since building > an agreed, trusted authority is tricky. > > (To say the obvious, I don't have the time to work on implementing either > approach. But I'm happy to have others do so. Something like this was > part of my original plans for SKS, but it never got done.) > > y > > On Sun, May 27, 2012 at 6:15 AM, Robert J. Hansen <r...@sixdemonbag.org>wrote: > >> On 5/27/12 5:50 AM, Giovanni Mascellani wrote: >>> I'm just a newbie here, but actually I'd like to see the same concept >>> applied in a more general way: I think there is much garbage in the >>> keyservers, even behind the PGP robo-signer. >> >> The problem here is this violates one of the principle design features >> of the keyserver network: >> >> "We never, never, never lose certificates." >> >> It is preferable for a keyserver to outright go down than it is for even >> one certificate to be lost. If a certificate is lost then a malicious >> actor could re-upload another key with the same short ID (a very easy >> thing to do), and that could facilitate all different kinds of attacks >> on people who don't properly validity-check certificates before using them. >> >> If the keyserver goes down then everyone knows in short order there's a >> problem. If a certificate is lost and silently replaced it might be a >> long time before being discovered. (Discovery is more likely if the >> keyserver is synchronizing with others, but there are a lot of >> standalone servers.) >> >> Further, expired certificates are still useful. I have some emails more >> than five years old that are still relevant and useful. If a >> certificate gets removed just because it expires, how am I to check the >> signature on those messages in order to ensure they haven't been >> tampered with? If the expired certificate remains on the servers, >> though, I can download it, validity-check it, and be confident in the >> integrity of my message. >> >> The same logic applies to revoked certificates: they're still useful for >> the same reasons. >> >> The keyservers never, never, never lose certificates. That's a design >> goal and one that the SKS maintainers believe is a good one. I agree >> with them, and want to see this design goal maintained in all future >> development. >> >> That said, welcome to the community, and please understand that although >> I think your idea is awful I'm honestly happy to see you here. :) The >> mailing list is a place where ideas come into violent collision, but we >> try to be reasonable human beings to each other. Welcome! >> >> _______________________________________________ >> 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 --- Ari Trachtenberg Assoc. Prof., Assoc. Grad. coChair, ECE trach...@bu.edu http://people.bu.edu/trachten _______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel