RE: Things to do - Requirement Document. Security.

[Krishna Sankar <ksankar@cisco.com>]

Michael,

	Good thoughts. Couple of observations:

|suggest we change the pitch of the message from "SHOULD allow" and "SHALL
|facilitate" to more permissive and broader "SHOULD NOT prevent" and "SHALL
|NOT make impossible".
|

	Sounds fine. But there would be many requirements which we might have to
express in active voice.

|know - the major participants and items, and associated security
|expectations.

	Keep in mind that we are talking about the requirements of a voting system,
not just security. So if there are non-security requirements, let us capture
them and move them to another section in the requirements document.

|	identification and traceability: << not quite a security issue, though>>
|	audit, identification and traceability: << not quite a security issue,
though>>

	We need these. Again, we are looking at all requirements, not just
security. Identification, audit et al are security functions anyway.

|Structuring security requirements this way will allow keeping it short and
|sweet, and hopefully better associated with the overall picture.

	Short, may be not. Sweet, depends :-) But I have no problem if you want to
restructure the points. Actually I was writing them as a straight list to
stimulate thoughts and didn't mean any organization.

|I believe that vote-casting environment should not be included into the
|security discussion. It has nothing to do with tokens/protocols.

	Again, we need to touch upon the vote casting environment in general terms
in the requirements section. The more generic the better, but still need to
include any assumptions, requirements, ...

cheers