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?
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.
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.
======
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.
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.
-------------------------------------------------------------------------
Attachment:
signature.asc
Description: This is a digitally signed message part