RE: [ALSC-Forum] Re: Direct vs. Indirect elections

[Bruce Young]

Eric wrote:

>Build your scenarios but they are only a way to keep me and my brothers
>and sisters from voting.

That's the intent: use twisted logic to justify disenfranchising users.


Bruce Young
Client Engineering
Lockheed Martin Global Telecommunications
Phone: 503.466.6571
Fax: 503.466.6775
E-mail:  Bruce.Young@nwdc.ibs-lmco.com



-----Original Message-----
From: owner-forum@www.atlargestudy.org
[mailto:owner-forum@www.atlargestudy.org]On Behalf Of Eric Dierker
Sent: Tuesday, October 09, 2001 7:58 PM
To: Stephen Waters
Cc: Sandy Harris; forum@atlargestudy.org
Subject: Re: [ALSC-Forum] Re: Direct vs. Indirect elections



Oh come on guys there are a thousand ways to verify.  I think it was
Mark Twain
who wrote, " I am sorry nigger but I don't know your daddy so your money
ain't
no good here boy"

Build your scenarios but they are only a way to keep me and my brothers
and
sisters from voting.

Sincerely,
Eric

Stephen Waters wrote:

> On Tue, 2001-10-09 at 10:32, Sandy Harris wrote:
> >
> > I see Kent's post as one of the few contributions actually trying to
deal
> > with that issue. Bravo, whether or not he came anywhere near getting the
> > right answer.
>
> Indeed, I'm very happy with Kent moving along instead of continuing his
> prior course of action.
>
> As to the question of voter authentication,
>
> Short answer: a PGP web of trust.
>
> Long answer: See how the Debian project* has maintained the integrity of
> its online codebase using PGP, and later, GPG (which is a libre
> implementation of the OpenPGP standard) over the past several years with
> contributors on all but one continent.
>
> Ring 0: Initially, you start off with one trusted key or a set of
> trusted keys. E.g., the keys of each member of the BoD.
>
> Ring 1: Those members then sign the keys of each of their respective
> regional councilmembers' keys.
>
> Ring 2: The regional councilmembers can then sign the keys of individual
> voters.
>
> Ring 3: Individual voters can sign keys of others.
>
> Ruleset:
> 0. All keys must be revokable, either top-down (database administrator
> revokes a known-to-be-compromized key) or by the user.
> 1. Anyone with a non-revoked key listed in the database can vote if it
> is signed by someone in Ring 0, 1, or 2.
> 2. There should be a minimum key strength.
>
> Refinements:
> 0. You could require 2 or more signatures, possibly of varying Rings.
> 1. You could add another Ring between 2 and 3 for district precincts
> within a region.
> 2. You could mandate key expiration dates.
>
> Drawbacks:
> 0. Actually GETTING your key signed. Debian throws "key signing parties"
> where developers bring their key on floppy and a photo ID and the
> trusted developers sign it.
> 1. Fraud at the district or regional level. It's not very different from
> voting precinct fraud, really, except you can just revoke any keys
> signed by the guilty parties and all the keys signed by them are no
> longer valid voting keys.
> 2. [1] might make it politically tempting to cry wolf. Disincentives
> like fee assessment and key revokation for intentional disruption exist,
> however.
> 3. Current lack of user-friendliness in many PGP products. I find
> Ximian's Evolution, gpg, and GnomePGP to be a powerful combination,
> though 2 of those components could certainly stand some refinement.
>
> Benefits:
> 0. Actually GETTING your key signed. This simple physical precaution is
> a good defense against fraud.
> 1. Eliminates much difference between indirect and direct election
> authentication possibilities.
> 2. Revokation and expiration can help ensure a set of valid keys.
>
> I typed this up pretty quickly, so there is plenty I probably missed. I
> do highly suggest digging around http://www.debian.org, particularly in
> the Developer's Corner!
>
> Cheers,
> -s
>
> * http://www.debian.org
>
>   ------------------------------------------------------------------------
>    Part 1.2Type: application/pgp-signature