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.


Michael,

	Thanks - good work. I am traveling today from UDDI meeting. By next week, I
will add your work to the requirements doc. As you have been thinking about
it, in your mind what other sections need to be there ?

cheers

|-----Original Message-----
|From: Michael Zolotarev [mailto:michael.zolotarev@baltimore.com]
|Sent: Friday, June 22, 2001 12:45 AM
|To: Krishna Sankar; Michael Zolotarev;
|election-services@lists.oasis-open.org
|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.
|It doesn't mention the identification and audit - I don't consider them to
|really belong there, in the security section.
|Any comments are welcome. << I know that English is not perfect. Feel free
|to fix it>>
|
|Regards
|Michael
|
|> -----Original Message-----
|> From: Krishna Sankar [mailto:ksankar@cisco.com]
|> Sent: Friday, 15 June 2001 17:35
|> To: Michael Zolotarev; election-services@lists.oasis-open.org
|> Subject: RE: Things to do - Requirement Document. Security.
|>
|>
|> 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
|>
|>
|>
|>
|> 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