Jason,
Good comments. Here are my observations.
1. We would add audit as another section. While we are on this subject,
what other sections do you see for the req document ?
2. The partial encryption is to *selectively* expose information. For
example for statistics purpose, one might have to look at the county
information, but not the actual voting. So there could be two encryptions -
one for county and one for actual vote. Again, the point is, we should not
make it *impossible* to do partial encryption. For all we know, we might do
full encryption.
cheers
|-----Original Message-----
|From: Jason Kitcat [mailto:]
|Sent: Friday, June 22, 2001 1:42 AM
|To:
|Subject: RE: Things to do - Requirement Document. Security.
|
|
|Hi,
|
|>The attached is [a very rough cut of] the security requirements
|for generic
|>Vote and Ballot tokens.
|
|Thanks for getting the ball rolling ;-)
|
|>It doesn't mention the identification and audit - I don't consider them to
|>really belong there, in the security section.
|
|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.
|
|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...
|
|regards,
|Jason
|
|--
| The FREE e-democracy project
|----------------------------------------
| http://www.free-project.org
|----------------------------------------
| secure, private and reliable Free Software
|
