On Sun, May 28, 2006 at 06:40:28PM -0500, Andrew McMillan wrote: >On Sun, 2006-05-28 at 04:54 -0700, Steve Langasek wrote: >>On Sat, May 27, 2006 at 04:47:20PM -0500, martin f krafft wrote: >> >>>I imagine an improved protocol for the keysigning, which is based on >>>an idea I overheard after the party (and someone mentioned it in the >>>thread): instead of the everyone-signs-everyone approach, it might >>>be interesting to investigate forming groups (based on connectivity >>>statistics) such that everyone's mean distance in the web of trust >>>can be increased by a fair amount in a short amount of time. At the >>>same time, such circles could be used for education by those with >>>high connectivity (and thus much experience). The problem here is of >>>course the somewhat unreliable attendance of people. Comments >>>welcome. >> >>I agree that this is the way to go. Who has time to work on implementing >>the necessary code?
[Sending to -devel only] I just talked to a friend who is an expert in mathematics (Senior Lecturer of Deakin University, Melbourne). He said the problem is a discrete programming problem and could be represented as a classical problem with a known solution algorithm. He will futher look into this problem. I'll do the coding of the optimization program (with his help). >It is something that has been discussed before, and it was certainly >something that I was discussing with Anibal after the keysigning. > >The concept that Anibal and I were discussing post-keysigning was as >follows: > >(a) Order the list of keysigning participants by centrality. > >(b) Decide on a group size for the keysigning. Something around 10-15 >seems likely to be a worthwhile choice. > >(c) Allocate partcipants to the groups in a round robin following >centrality order and starting with the most central. To allocate participants in each group we'll use the optimization program to improve the mds of all ksp participants. >Produce the keysigning list, with group numbers in addition to the key >numbers (or perhaps instead of). > >All of the other pre-keysigning activities are the same. > >At the keysigning, the initial reading out of MD5 / SHA1 of the >keysigning list would still happen, as it normally does. > >After this, the keysigning would follow two parts: > >Part One >======== > >People split into their assigned groups and cross-sign only within those >groups. The intention is that these groups are small enough that >everyone can see everything that is going on. Experienced people can be >observed performing comprehensive checks, and inexperienced people can >be educated. > >Part Two >======== > >Optionally, after part one is complete, some people may choose to >personally and individually participate in keysignings outside of their >assigned groups. Note that this can still be facilitated by the fact >that both individuals have their fingerprints within the keysigning >list. The group of "Part Two" could consist of people with the lowest mds and people who want to participate in keysignings outside of their "Part One" groups. >====== >Finito. >And gradually it fades out. > > >Rationale >========= > >Keysignings stop being fun ways to meet people after about 15 minutes. >For me, the worst experience was in Helsinki, with around 300 people, >getting sunburned in a carpark. > >Keysignings are about improving the web of trust. The most efficient >enhancement of the web of trust will be if the edges exchange keys with >the middle. Signing keys with _everyone_ is inefficient, unnecessary >and promotes competitive behaviour rather than trust relationships. > >Keysignings should promote education of WoT best practices, and not >_worst_ practices. > >Keysignings should not take more than one hour. > > >So that's my 2c. > > >If people agree that this would be a useful approach, I am willing to >undertake to provide some additional tools within the signing-party >package to make such a keysigning more easily doable. > >Of course the above does not address how to handle the people who didn't >manage to get their act together soon enough to be in the initial list. >There are several ways to deal with this also: > >1) The "additional list" is produced, SHA1'd, read, but these people can >only participate in "Part Two" above. > >2) The "additional list" is produced.... and these people are also >allocated to groups in round robin, but randomly, rather than in >centrality order. Or we could use the optimization program to allocate people in the "additional list" to the small groups. >and no doubt there are other ways to deal with it... > > >Regards, > Andrew. > >PS. Please feel free to CC me on replies, since I am not subscribed to >Debian Devel and I _do_ have sane procmail dupe filters :-) > >------------------------------------------------------------------------- >Andrew @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington >WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St >DDI: +64(4)803-2201 MOB: +64(272)DEBIAN OFFICE: +64(4)499-2267 > Be different: conform. >------------------------------------------------------------------------- Best Regards, Aníbal Monsalve Salazar -- http://v7w.com/anibal
signature.asc
Description: Digital signature
