Jerome Baum wrote: > On 2012-01-28 06:14, Robert J. Hansen wrote: >> It isn't just that no one's written the code: it's there's no community >> consensus to deploy such code, even if it were written. It would be a >> pretty major flag day. After all, if one keyserver enforces it and >> others don't, then that's going to create a pretty obvious syncing problem. > > What syncing problem is that? Wouldn't the crypto-supporting keyserver > simply sync out (provide to other keyservers) it's published packets and > sync in everything (yet drop packets without a "publish" signature)? > > (So in this scenario I'm assuming the key owner adds e.g. a > self-signature with a special notation listing the packets that they > want to be published on the keyserver.) > > Or was this more about "old" keys -- that don't have the special > self-signature -- dropping out of the network? How about making the > publish control optional -- if the self-sig doesn't say "I want to > control my published stuff" then just publish all packets?
You've just outlined the problem. The present behavior of all keyservers is to merge packets. If the no-modify behavior is introduced, that server is going to drop or refuse packets. How do you reconcile keys when you have two legal behaviors in place within the network? Differing copies of a key is _NOT_ an option. The thing that makes SKS so fast is its reconciliation scheme which relies on logically identical or near identical copies of the keystore. If two variant copies of the same key are allowed to exist, they will endlessly be exchanged between servers, thus crippling the reconciliation process as more no-modify keys are sent to the keyservers. It has nothing to do with what is or isn't published. You ask for key 0xdecafbad, you get all of the key. What it has to do with is _what_ gets stored and how those decisions are made. Differing algorithms equate to differing keys. I tagged SKS 1.1.2 at the end of September. Currently there are four versions of SKS running in the network: 1.0.10, 1.1.0, 1.1.1, 1.1.2. I think the 1.0.9 servers finally upgraded. Getting all servers on the same release would in itself be a large undertaking and would be required for a no-modify scheme to work. I don't see a way that a rolling-upgrade to a no-modify supporting version could be accomplished without breaking things in the process. The only way I can envision doing this to to form a completely new network and let servers migrate into it as they upgrade to the no-modify supporting version. In a way, that's also undesirable as it divides the widely distributed network in two. There's really no simple way to retrofit no-modify behavior into an existing keyserver network. -- John P. Clizbe Inet:John ( a ) Enigmail DAWT net FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or mailto:pgp-public-k...@gingerbear.net?subject=HELP Cowboy Haiku -- Reflections on Rodeo So many Cowboys. / Round Wrangler butts drive me nuts. / Never enough rope.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users