> 1. We would have to ensure that all keyservers block the same > uploads. One permissive keyserver is a backdoor into the entire > system. We can’t block bad keys at reconciliation time for the same > reasons that have been hashed to death already.
One way to do that, though it would mean officially sunsetting SKS, might be to: 1. Publish an update to SKS that: - Blocks all uploads of any packet that is not a revocation signature packet (maybe also having to check the revocation is actually correctly signed, to avoid flooding of revocation packets to become the new flaw) - Embeds a hardcoded list of already-disrupted keys for which packets should be filtered-out when serving them 2. Pressure keyserver operators into updating 3. Kick all not-up-to-date keyservers from the pool after some delay deemed acceptable (shorter means less broken GnuPG, longer means less keyservers kicked out) Note: I do not know how the pool is handled. Maybe this would mean that the new update to SKS would need to stop synchronizing with earlier versions, and that the hkps pool should be turned off until enough keyservers are updated to handle the load? Do you think such a plan might be reasonably done, to at least keep the most basic functionality of not breaking existing installations and allow them to keep revocations flowing? The biggest issue I can see is it requires a quite big amount of development work. Hope that helps, Leo _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users