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. Security.


Hi all,

	The question is not whether we need any *special* audit trails different
from the current practices in Financial and other industries, but whether to
add it as a requirement in the security section of the requirements
document. I agree with Jason that we need to add it.

	If there are practices followed in financial and other sectors, it is fine
because then we can, in our specs, satisfy this requirement by following the
same practices. On the other hand may be there are some differences like the
voting (audit) records are open to public at some point, while financial
records are not public. So, may be, we might need some practices in the
audit trail which is specific to the voting domain.

	Jason, can you articulate some unique audit trail requirements in this area
?

	I also would like to ask the folks, who have experience in voting systems,
to give us some ideas on the unique audit trail needs.

cheers

|-----Original Message-----
|From: Michael Zolotarev [mailto:michael.zolotarev@baltimore.com]
|Sent: Sunday, June 24, 2001 5:03 PM
|To: Jason Kitcat; election-services@lists.oasis-open.org
|Subject: RE: Things to do - Requirement Document. Security.
|
|
|Jason,
|> I'd have to disagree. If you don't think about the security/privacy
|> implications of providing, for example, audit trails now then it may
|> prove difficult to retrofit them later.
|
|In my opinion, audit trail requirements (as much as archiving) present no
|specific implications for voting. What's the difference between an audit
|trail of financial transactions records and voting records, for
|instance? No
|much, let me say. Audit trail kept securily, in authenticated way, with the
|records chained and optionally signed, to prevent altering. The same
|commercial audit trail system, if there were one around, would be
|appropriate for providing audit trails for voting, financials, and whatever
|else. The actual structure of a token, and its inner security, have very
|little significance for the general audit trailing, IMO.
|What does have some importance for audit trails, though, is that each token
|may need to have some sort of a key, or a unique ID, to facilitate
|search/sortering/retrieval. But this is a far from the security as anything
|can be.
|
|>
|> Also you say:
|>
|> >Note. It SHALL be possible to encrypt only certain components of the
|> >complete vote structure, rather >than encrypting the whole lot.
|>
|> And the same again with regards to ballots. I don't see what you're
|> trying to say/achieve by this because plainly the entire vote
|> structure could be encrypted with something like SSL or just a hand
|> rolled encryption solution. Please explain...
|
|Yes, you are right saying that we should also be able to partially encrypt
|ballots.
|
|Why partially encrypt? Imagine a vote, which has a common header with the
|elements/attributes used for classification, transmittion, sorting, storing
|etc. And a field which contains the actual "Vote" - the voter's specific
|choice. The voting system processes the vote token (including sending it
|around a lot) based on the header information. And only after the vote
|reached the election HQs, the vote gets counted. It's quite reasonable to
|have the vote encrypted for the HQs, so that nobody can steal/modify it, at
|the same time leaving the rest- ie headers and whatever else, in clear.
|
|
|>
|> regards,
|> Jason
|>
|> --
|>             The FREE e-democracy project
|> ----------------------------------------
|>             http://www.free-project.org
|> ----------------------------------------
|>   secure, private and reliable Free Software
|>
|>
|> This footnote confirms that this email message has been swept by
|> MIMEsweeper for the presence of computer viruses.
|>
|
|
|-------------------------------------------------------------------
|----------------------------------------------
|"How can I make sure the right people get access to the right resources
|and business applications, with a user base that's constantly growing and
|changing?"
|The answer...
|Baltimore SelectAccess
|Next Generation Authorisation Management
|http://www.baltimore.com/selectaccess/index.html
|-------------------------------------------------------------------
|----------------------------------------------
|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