Public SourceMage Discussion List

["Jeremy Blosser (emrys)" <jblosser-smgl AT firinn.org>]

On Jan 04, Sergey A. Lipnevich [sergey AT sourcemage.org] wrote:
> Jeremy Blosser (emrys) wrote:
> > And if someone didn't sign their vote, and verification is requested, what
> > does that mean?  They have to vote again, and sign it the second time?
> > And what would then be the time limitation on people being able to ask for
> > verification?  We would be unable to verify votes on request if the person
> > who cast an unsigned vote couldn't be located to verify it.
> 
> And what is the likelihood of these things happening?

One might hope that the likelihood of someone wanted to confirm votes were
not tampered with is pretty high.  In fact, that's basically why signing
was brought up, various people want to verify the votes.  They're just
asking between votes.  Saying we have to wait til after a vote happens just
means someone gets to make a point out of asking for verification after
every vote is reported.

> Don't forget that the email has a header and if need be, we can look at
> the complete trace to see where it's coming from and if other emails from
> the same person follow this pattern. Essentially, I'm saying "there are
> ways to do basic verification without signatures if it is necessary, but
> the necessity of this is quite unlikely."

Someone who wants to modify a mailed vote isn't going to do it in a way
that changes the headers unless they're an idiot.  Even if we assume that
no server between the developer and the vote counter is malicious, consider
that if/when we host our own mail some of the people being voted for will
have sufficient access to the mailflow to make the votes say whatever they
want without touching the headers.  Signatures are the only way to ensure
that the content of the message came unmodified from the person that claims
to have sent it, because they are a hashsum attached to a verified
identity.

> > This would definitely require SSL protection on at least that part of the
> > drupal site.  Since we can't afford a verisign cert, that also means all
> > developers would need to allow a 3rd party cert or CA on their browsers,
> > with appropriate verification.
>   
> I don't trust Verisign much anyway after their recent stunts, although I 
> have to kind of trust them every time I buy something online, because I 
> have no choice. Self-signed certificates are appropriate for a voting 
> application I think. Eric can sign the certificate so we know it can be 
> trusted, and that's it. I hope he charges less than Verisign for this :-).

That's not really how it works.  Eric would have to create a CA to do that,
and we'd all have to verify his CA somehow.  Theoretically his GPG key
could be used there but that doesn't really scale to our entire user
community for other parts of the site we might want secure, such as the
voting results page itself.

> Authentication on the site has to be protected regardless of the voting 
> issue, so it's only for the best that we do it.

Most likely we'll want to get CACert cert(s) on the relevant sites.  They
have some browser penetration and people can be reasonably expected to have
their root certs or get them.  Also we have multiple CACert assurers on the
team already, so we can do our own certs.

However, I'm not in favor of moving voting to the web sites.  It's a whole
lot easier to audit an emailed vote.  If it's in drupal we have to be able
to audit the vote from the browser to the web server to the database to
some external record.  Even if we use SSL between the user and the web
site, once submitted anyone with access to the web server or drupal's
components or the database can change it.  The best way to do verification
end-to-end would still be to have developers sign their votes before
injecting them into the system.

Attachment: pgpeGeJ02Iijl.pgp
Description: PGP signature