Re: meeting re: defining requirements for cryptographically verifiable voting software?

[Vincent Untz <vuntz gnome org>]

Le mardi 06 mars 2007, à 17:43, Ben Adida a écrit :
> Vincent Untz wrote:
> > Let's at least come with this:
>
> This is a very useful start.
>
> >  + it's not possible to know who a voter voted for (anonymisity)
> >  + except for the voter, who can verify that is vote has been correctly
> >    taken into account
> >  + "it just works" for voters: no difficult setup for them. Web
> >    interface is okay, mail interface could be okay, although it's less
> >    friendly
> >  + if the voter needs a token to login, the token has to be
> >    'reissuable' (ie, we can invalidate the old token if it hasn't been
> >    used and create a new one for the voter)
> >  + the voter needs to confirm at least once his vote so that he's sure
> >    he made no error
> >  + ideally, nobody should be able to have an idea of the current state
> >    of the votes before the voting period ends
> >  + we have results ASAP
> >  + the system should be able to deal with elections and referenda
> >
> > I'm probably forgetting things. And I didn't assume the election was
> > held in a single physical location :-)
>
> Okay, all of the above sound fairly straight-forward for a voting system
> (not trivial to implement, but certainly features one expects.)
>
> Now, with respect to the kinds of questions that are asked in these
> elections/referenda:
>
> - do you need write-in candidates?

Is this "voting for someone who's not officially candidate"? If that's
it, then no.

> - do you need candidate ranking, for instant runoff?

Yes.

> - do you have committee elections (i.e. "pick 5 of the following 10")?

Yes. Right now, it's "pick 7 of all the candidates".

Oh, and a small detail: no more than 40% of the elected people can work
for the same company. Ie, right now, no more than two Foundation
directors can work for Red Hat. Or Novell. Or Sun. But we can two people
from Novell, two people from RH and two people from Sun (and someone
else).

> > > Second, what are you current authentication bootstraps? Does everyone
> > > have an SSH key? An SSL client-side cert? A username/password?
> >
> > Nothing :-) That's a big issue.
>
> Or it could be a good thing: this means we don't need to support any
> existing mechanism for authentication :)
>
> In terms of effort made by a user, do the following seem acceptable:
>
> 1) generate an SSH keypair for the election.
> 2) generate a web client-side certificate for the election.

1 is doable too, since seahorse supports generating and handling ssh
keys. I'm not sure about 2, but the only time I generated a certificate
via the web, it was quite painful (I don't know if it has to be painful
or not).

Thanks,

Vincent

-- 
Les gens heureux ne sont pas pressés.