On 2019/02/06 23:51, Robert J. Hansen wrote: > No. Keyserver reconciliation is 90% of the problem. Fixing this would > make it impossible for older keyservers to reconcile with a next-gen design.
I have had a long think about this problem, and I reckon that the biggest bar to progress is the assumption that arbitrary members of the pool will upgrade to the new software at random, and that we need to ensure that all nodes stay synchronised with each other no matter what version they run, in a single mixed-version network. We can simplify this problem considerably. Instead of an operator upgrading their sks server to "new-sks" and expecting to still be able to peer with traditional sks servers, they should install the "new-sks" software *in parallel* with the traditional one (on the same or a different machine, doesn't matter) and this "new-sks" node should only be able to peer with other "new-sks" nodes. This means that our new recon protocol can be efficient, because it doesn't have to keep a record of blacklisted hashes. If we further assume that key material does not flow back from the "new-sks" network to the old one, then we can write a relatively simple cron job that finds updated keys on an old-style sks server (by parsing its logs, for example) and copies them (suitably censored) to the corresponding "new-sks" server. At some point, when the "new-sks" network is sufficiently stable, the pools are redefined and the old sks network becomes irrelevant. The above allows us to ignore broad categories of problematic material by policy, simply by defining a narrow set of allowed packets in the new protocol. Any compliant "new-sks" server will simply not be capable of processing packets of unapproved types, e.g. image IDs, 3rd party signatures, and keys with invalid self-sigs. Also, any peer that tries to serve too many unapproved packets via recon can be twitted. What the above will not do is allow individual operators to blacklist arbitrary packets by hash, not without either some central authority defining a shared blacklist, or a fake-recon process that maintains local blacklist caches and runs the risk of split-brain. So the threat of shutdown by court order is not completely removed. I still think this may be enough to be getting started with. A
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel