OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

election-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: Things to do - Requirement Document


Kevin,

	We are aiming at a global reach ! There are folks in UK, Europe et al who
want to conduct elections using our specification. (And it is more fun that
way !) Also, there are some good practices from UK/Europe which we can
introduce in the US (especially in Florida:-))

	Thanks for the insight. You are right, we should follow the money and get
their requirements as well.

cheers



|-----Original Message-----
|From: Kevin Broadfoot [mailto:KBroadfoot@baltimore.com]
|Sent: Thursday, June 14, 2001 7:53 AM
|To: 'Krishna Sankar'
|Subject: RE: Things to do - Requirement Document
|
|
|Krishna- I haven't commented before now but ....!
|
|What jurisdiction are you focusing on? Just the US or do you want to create
|something that could be applied globally?
|
|Second thought  - the market for vendors is not the electorate or
|politicians.  The market is the election administrator ...  you
|need to find
|out what they want because they are the people with the budgets to spend.
|
|kind regards,
|
|Kevin Broadfoot.
|
|Baltimore Technologies (UK) Ltd.  Innovation House, Mark Road, Hemel
|Hempstead, HP2 7DN. UK
|
|
|-----Original Message-----
|From: Krishna Sankar [mailto:ksankar@cisco.com]
|Sent: 14 June 2001 07:25
|To: election-services@lists.oasis-open.org
|Subject: RE: Things to do - Requirement Document
|
|
|Hi,
|
|	Here are some thoughts on security requirements:
|
|	1.	Each voter should be authenticated.
|	2.	Each voter should be authorized
|	3.	Voters should be able to verify that their vote is
|registered
|	4.	There should be no linkage between the voter and a vote.
|i.e. the votes
|themselves should be anonymous
|		(Question : Should we also allow optional linkage ? May be
|in many
|circumstances, we do want to know who voted for what.)
|	5.	There should be no indirect voter to vote linkage. i.e. this
|relation
|shouldn't be derivable based on some other factors (for example by
|correlating time in a log or a location or a serial number or other similar
|pieces of information)
|		(Note : This is true even when we allow direct linkage. The
|point is
|direct linkage if allowed would be the ONLY way to link a voter
|with a vote)
|	6.	Each vote could have some location information like a county
|or similar
|geographic location. This is used for statistical purposes
|	7.	Transmission of results and other voting related information
|should be
|secured
|	8.	Transmission of voting should be secured
|	9.	Security should be the first priority for voting and related
|systems
|	10.	The system should be able to generate, handle and deliver
|time locked
|information
|	11.	The system should be able to handle policies which could be
|different
|at different locations - physical or logical
|	12.	The policy admin privileges should be secures and policy
|changes should
|be logged
|	13.	The various systems should have logging and auditing
|facilities - many
|of them capable of forming permanent and unalterable records with
|non-repudiation capabilities built-in
|	14.	The logging and audit trails should not violate other
|requirements like
|the anonymous voting.
|	15.	The system should be able to catch security in-consistencies
|for known
|voting models. i.e. the security policies of known voting models should be
|pre-programmed and should not be altered
|
|cheers
|
||-----Original Message-----
||From: Krishna Sankar [mailto:ksankar@cisco.com]
||Sent: Tuesday, June 12, 2001 6:37 PM
||To: election-services@lists.oasis-open.org
||Subject: Things to do - Requirement Document
||
||
||Hi all,
||
||	This is a concise document which will have the
||requirements. Sections would
||include general, security, interfaces, presentation, ... We would
|base this
||document for developing the specifications. The goal is to develop a
||specification which reflects the requirements.
||
||	We need an owner for this document as well. I can take a
||first cut at this.
||
||	Please send me your ideas, suggestions, what you want to
||see as a part of
||the specifications,...
||
||cheers
||
||
||
|
|
|
|This footnote confirms that this email message has been swept by
|MIMEsweeper for the presence of computer viruses.
|
|
|-------------------------------------------------------------------
|----------------------------------------------
|The information contained in this message is confidential and is intended
|for the addressee(s) only.  If you have received this message in error or
|there are any problems please notify the originator immediately.  The
|unauthorized use, disclosure, copying or alteration of this message is
|strictly forbidden. Baltimore Technologies plc will not be liable
|for direct,
|special, indirect or consequential damages arising from alteration of the
|contents of this message by a third party or as a result of any
|virus being
|passed on.
|
|In addition, certain Marketing collateral may be added from time
|to time to
|promote Baltimore Technologies products, services, Global e-Security or
|appearance at trade shows and conferences.
|
|This footnote confirms that this email message has been swept by
|Baltimore MIMEsweeper for Content Security threats, including
|computer viruses.
|



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC