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
