[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Debconf-discuss] Alternative keysigning procedures

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
>>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
>(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

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.

>And gradually it fades out.
>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...
>					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

Attachment: signature.asc
Description: Digital signature

Reply to: