RE: [election-services] RE: EML TC MEETING AGENDA

[John Ross <ross@secstan.com>]

To do any standardisation work there is a need for a model.  I assume this
will be done as part of defining the architecture. Thus the architecture
paper will identify the interface points were standard schema will apply.

However, I agree that the security paper makes some assumption about the
architecture, which may or may not turn out to be true.

In the security paper it is assumed an I-voting service has three possible
standardised interface points, Voter application, Ballot delivery  and Vote
delivery (this comes from the list of XML schema the group is trying to
agree standards for).   That does not mean that every system implemented
will have to interoperate with every other systems at all the standard
interfaces, but if they do then they will need to support the standard
schemas and have security mechanism that meet the requirement at that
interface.

As for GNU.FREE, as you explained the voter gets a client application which
already contains the 'ballot'.  In which case GNU.FREE will not need to
support the ballot delivery schema and hence will have no need for standard
security features which support the ballot delivery schema.

I have look at the paper again and tried to take out any specific PKI and
digital signature references.  However, PKI, certificates and digital
signatures are a valid digital id solution, but not the only one.

Regards

John




-----Original Message-----
From: Jason Kitcat [mailto:jeep@free-project.org]
Sent: 18 October 2001 15:39
To: election-services@lists.oasis-open.org
Subject: RE: [election-services] RE: EML TC MEETING AGENDA


Hi,


>I have amended the text in Para 4.3 to make it more general.  Is that OK?

Thank you for doing that. However the subsequent section which begins:

"The procedures required to support I-voting are illustrated below:"

then details a procedure which includes references to 'signatures',
'key pair'. Furthermore the system implies that some kind of
identifying information is sent with a vote which can be seperated
from the actual vote at the discretion of the registrar. It also
details the concept of sending the system a 'form' to prove one
should be able to vote, and then a ballot is returned to the voter.

All of these things shouldn't be specified as a system doesn't
necessarily have to work that way. Thus in GNU.FREE the voter gets a
client application which already contains the 'ballot' as such. The
user is authenticated by one server and then sends the vote to
another server. The only keypairs user are on transport level
encryption and no signatures are used at all.

I not trying to be obstructive but I feel that we need to step back
and not overspecify all of this. AFAIK we are specifying something to
allow interoperability - thus we shouldn't make too many assumptions
on how existing or future system do or might work.

regards,
Jason

--
            The FREE e-democracy project
----------------------------------------
            http://www.free-project.org
----------------------------------------
  secure, private and reliable Free Software

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

I-voting XML security reqv3.doc