- From: Read, Martin (AU - Adelaide) <mread@deloitte.com.au>
- Date: Fri, 10 May 2002 09:32:06 +1000
- To: "'Ahmed, Zahid'" <zahid.ahmed@commerceone.com>, www-ws-arch@w3.org
- Message-ID: <CDDF6190494B6648934181A2719E72C103A68065@ausyd0405.au.deloitte.com>
Me too - auditing should not be included...........
Martin Read
-----Original Message-----
From: Ahmed, Zahid [mailto:zahid.ahmed@commerceone.com]
Sent: Friday, May 10, 2002 5:47 AM
To: www-ws-arch@w3.org
Subject: RE: D-AR006.11 discussion points
I agree that auduting should not be included in the security
requirements.
NR also potentially falls into the scope of messaging rather
than security although it uses security primitives.
---Zahid
-----Original Message-----
From: Krishna Sankar [ mailto:ksankar@cisco.com <mailto:ksankar@cisco.com> ]
Sent: Wednesday, May 08, 2002 7:20 PM
To: www-ws-arch@w3.org
Subject: RE: D-AR006.11 discussion points
Just to add to Sandeep's point, security auditing is a security
requirements, for proposes like IDS, access logs et al.
Non-repudiation is not a security function. Agreed, it is based on
primitives which security is also based on - like signatures and so on.
In fact non-repudiation is not only a technological issue but also a
legal issue. The pkix forum is having mile long discussions on this.
The process required to prove the validity of a document (origin,
receipt, contents) beyond doubt, in front of an arbitrator, at a future
date ( up to 7 years from now) is complex and beyond the scope of
security. One example is, the key strength - what is deemed
non-repudiable now need not be non-repudiable six years from now -
because of the weakness of the keys. i.e. keys which cannot be broken
now would be dissectible few years from now and so the records are no
more irrefutable.
Just my 2c (You might not be able to prove it though :o)
cheers
| -----Original Message-----
| From: www-ws-arch-request@w3.org
| [ mailto:www-ws-arch-request@w3.org <mailto:www-ws-arch-request@w3.org> ]
On Behalf Of Sandeep Kumar
| Sent: Wednesday, May 08, 2002 5:26 PM
| To: www-ws-arch@w3.org
| Subject: RE: D-AR006.11 discussion points
|
|
|
| Folks,
|
| Isn't it the case that to accomplish Non-Repudiation one has
| to implement auditing of some kind? If so, Auditing DOES NOT
| belong in security
| architecture discussions or is NOT A REQUIREMENT.
|
| Comments?
|
| Sandeep Kumar
| Cisco Systems
|
| Joseph Hui wrote:
|
| >>-----Original Message-----
| >>From: Christopher Ferris [ mailto:chris.ferris@sun.com
<mailto:chris.ferris@sun.com> ]
| >>Sent: Wednesday, May 08, 2002 3:50 PM
| >>To: Joseph Hui
| >>Cc: Dilber, Ayse, ALASO; www-ws-arch@w3.org
| >>Subject: Re: D-AR006.11 discussion points
| >>
| >>
| >>Joe,
| >>
| >>What is a "security primitive" per se? My understanding of
| security is
| >>based on the premise of risks and balanced countermeasures
| based on
| >>the level of risk assessed for each resource. I have never
| heard of a
| >>"security primitive" before so I have no idea how to respond
| >>to your question.
| >>
| >
| > Off the top of my head, the established security primitives
| > include: encryption (for Confidentiality); message digest
| (for data
| > Integrity; Public Key Encryption (PKE, for key
| establishment, which
| > may be further broken down to key exchange and key
| agreement); digital
| > signature (for non-repudiation), ... I think you get gist by now.
| >
| > (Just like doing computer graphics, you have point,
| > draw, fill, ... as graphic primitives.)
| >
| >
| >>IMO, auditing as a service *might* be something we
| >>consider as an important aspect of web services
| >>security.
| >>
| >
| > I agree it can be important, but not to the point of
| > being the equal of the original six.
| >
| >
| >>Or, we might conclude that in terms of priority
| >>that other countermeasure technologies should be
| considered ahead of
| >>auditing. But that's beside the point.
| >>
| >>The six "facets" you cite are in fact (IMHO) merely six
| >>countermeasures which comprise but a subset of the total
| arsenal of
| >>countermeasures that might be applied to mitigate a risk.
| Auditing is
| >>another, equally valid, countermeasure that is (or should
| be!) often
| >>employed within the fabric of a secure environment. There are
| >>other non-technical (and IMHO, far more important)
| >>countermeasures (management comes to mind, without which
| >>all the glitzy technicological countermeasures one
| >>can imagine can be rendered useless overhead) that could
| >>also be included in the list.
| >>
| >
| > Are we going to roll admin/operational elements into the
| mix now? I
| > thought there was already enough grief given to D-AR006.7
| through 6.8.
| > They are admin/operational-ish.
| >
| >
| >>Why is it that you are so adamantly opposed to its (Auditing)
| >>inclusion in this list?
| >>
| >
| > Let's not jump to conclusions. I haven't made up my mind
| yet whether
| > to oppose it, let alone adamantly. For Pete's sake, what's
| the final
| > wording of the req?
| >
| > I have already expressed my reservation about grouping
| Auditing in as
| > a sec aspect. (Ayse was having mail problem and I'm still
| waiting on
| > the response that she said she'd sent me.) And I've
| already responded
| > (favorbly, mind you :-) to the one proposed by Steven A. Monetti.
| >
| >
| >>A number of others have chimed in suggesting
| >>that its inclusion would be "a good thing(tm)".
| >>
| >
| > No argument ever from me against Auditing being a good thing.
| >
| >
| >>Would you be willing to live with its inclusion?
| >>
| >
| > Inclusion as a separate req; or inclusion as replacement
| to supplant
| > the original six? Like implied earlier, I can live with
| the simple
| > wording proposed by Steven. Will that be the final wording?
| >
| > Cheers
| >
| > Joe Hui
| > Exodus, a Cable & Wireless service
| > =========================================
| >
| >>Cheers,
| >>
| >>Chris
| >>
| >>
| >>
| >>Joseph Hui wrote:
| >>
| >>
| >>>>From: Christopher Ferris [ mailto:chris.ferris@sun.com
<mailto:chris.ferris@sun.com> ]
| >>>>Sent: Wednesday, May 08, 2002 2:25 PM
| >>>>To: Joseph Hui
| >>>>Cc: Dilber, Ayse, ALASO; www-ws-arch@w3.org
| >>>>Subject: Re: D-AR006.11 discussion points
| >>>>
| >>>>
| >>>>Joe,
| >>>>
| >>>>As with AuthN and AuthZ, it is a countermeasure used
| >>>>to mitigate a security threat(s) such as when AuthN and
| AuthZ have
| >>>>been (somehow) circumvented. It is also useful to
| protect against
| >>>>abuse of privileges that may have been granted.
| >>>>
| >>>>
| >>>Chris,
| >>>
| >>>I'm well aware of the benefits of auditing -- nuts and
| >>>bolts and trimmings; and what auditing may mean in
| various contexts.
| >>>(Exodus is a well established vendor of Security Audit services,
| >>>albeit Ayse's notion of Auditing is more like logging and our
| >>>products cover far more than that.)
| >>>
| >>>However, I wouldn't elevate it to a "security
| aspect/facet" equal to
| >>>the original six commonly known to security experts. The
| experts no
| >>>doubt know what Auditing can mean in the context of security, but
| >>>wouldn't group it in the company of the original six for sure.
| >>>
| >>>Can you think of a security primitive that does Auditing?
| >>>
| >>>Cheers,
| >>>
| >>>Joe Hui
| >>>Exodus, a Cable & Wireless service
| >>>=================================================
| >>>
| >>>
| >>>
| >>>
| >>>
| >>>>Cheers,
| >>>>
| >>>>Chris-sans-chapeau
| >>>>
| >>>>Joseph Hui wrote:
| >>>>
| >>>>
| >>>>
| >>>>>>-----Original Message-----
| >>>>>>From: Dilber, Ayse, ALASO [ mailto:adilber@att.com
<mailto:adilber@att.com> ]
| >>>>>>Sent: Wednesday, May 08, 2002 2:02 PM
| >>>>>>To: Joseph Hui; Christopher Ferris; www-ws-arch@w3.org
| >>>>>>Subject: RE: D-AR006.11 discussion points
| >>>>>>
| >>>>>>
| >>>>>>i don't know if you will receive this but i'm having lots of
| >>>>>>e-mail problems today, i thought i answered your question in
| >>>>>>a different message but it sounds like it wasn't delivered.
| >>>>>>so here it is:
| >>>>>>
| >>>>>>
| >>>>>>
| >>>>>Well, here it is what? Another mail problem? ;-)
| >>>>>Please take your time, Ayse.
| >>>>>Fix you mail first; the world can wait. :-)
| >>>>>
| >>>>>Joe Hui
| >>>>>Exodus, a Cable & Wireless service
| >>>>>=============================================
| >>>>>
| >>>>>
| >>>>>
| >>>>>>-----Original Message-----
| >>>>>>From: Joseph Hui [ mailto:Joseph.Hui@exodus.net
<mailto:Joseph.Hui@exodus.net> ]
| >>>>>>Sent: Wednesday, May 08, 2002 4:41 PM
| >>>>>>To: Dilber, Ayse, ALASO; Christopher Ferris; www-ws-arch@w3.org
| >>>>>>Subject: RE: D-AR006.11 discussion points
| >>>>>>
| >>>>>>
| >>>>>>Ayse,
| >>>>>>
| >>>>>>Then what's your answer to my questions in [1]
| >>>>>>pertaining to threat characterization?
| >>>>>>
| >>>>>>I'm copying the text of the original question over
| >>>>>>as follows:
| >>>>>>
| >>>>>>Auditing* as a security aspect?
| >>>>>>Can you explain why? E.g. for starter, how would you
| characterize
| >>>>>>the threat (model) that's unique to Auditing? Note that the
| >>>>>>impetus for requiring each of the original six begins with a
| >>>>>>unique threat, or in some cases, threats.
| >>>>>>
| >>>>>>Joe Hui
| >>>>>>Exodus, a Cable & Wireless service
| >>>>>>
| >>>>>>PS: I wasn't interested in what auditing means in
| >>>>>> the conventional sense. It's obvious.
| >>>>>>
| >>>>>>[1]
| >>>>>>
| >>>>>>
| >>>> http://lists.w3.org/Archives/Member/w3c-ws-arch/2002May/0056.html
<http://lists.w3.org/Archives/Member/w3c-ws-arch/2002May/0056.html>
| >>>>
| >>>>
| >>>>>>============================================================
| >>>>>>
| >>>>>>
| >>>>==========
| >>>>
| >>>>
| >>>>>>>-----Original Message-----
| >>>>>>>From: Dilber, Ayse, ALASO [ mailto:adilber@att.com
<mailto:adilber@att.com> ]
| >>>>>>>Sent: Wednesday, May 08, 2002 12:59 PM
| >>>>>>>To: Joseph Hui; Christopher Ferris; www-ws-arch@w3.org
| >>>>>>>Subject: RE: D-AR006.11 discussion points
| >>>>>>>
| >>>>>>>
| >>>>>>>No, I didn't back out on Auditing! I was having serious
| >>>>>>>e-mail problems that's why I couldn't respond. I believe
| >>>>>>>that the Auditing should be included!
| >>>>>>>Ayse
| >>>>>>>
| >>>>>>>-----Original Message-----
| >>>>>>>From: Joseph Hui [ mailto:Joseph.Hui@exodus.net
<mailto:Joseph.Hui@exodus.net> ]
| >>>>>>>Sent: Wednesday, May 08, 2002 3:55 PM
| >>>>>>>To: Christopher Ferris; www-ws-arch@w3.org
| >>>>>>>Subject: RE: D-AR006.11 discussion points
| >>>>>>>
| >>>>>>>
| >>>>>>>
| >>>>>>>
| >>>>>>>
| >>>>>>>
| >>>>>>>
| >>>>>>>>-----Original Message-----
| >>>>>>>>From: Christopher Ferris [ mailto:chris.ferris@sun.com
<mailto:chris.ferris@sun.com> ]
| >>>>>>>>Sent: Wednesday, May 08, 2002 12:00 PM
| >>>>>>>>To: www-ws-arch@w3.org
| >>>>>>>>Subject: Re: D-AR006.11 discussion points
| >>>>>>>>
| >>>>>>>>
| >>>>>>>>Joe/Ayse,
| >>>>>>>>
| >>>>>>>>1) Please keep this, and all technical discussion,
| on the public
| >>>>>>>>mailing list.
| >>>>>>>>
| >>>>>>>>2) It seems to me that Joe is suggesting that the
| bulleted item
| >>>>>>>>under D-AR006.11 that says:
| >>>>>>>>
| >>>>>>>>"There are six aspects in the security framework for Web
| >>>>>>>>Services architecture: Accessibility,
| >>>>>>>>Authentication, Authorization, Confidentiality, Integrity,
| >>>>>>>>and Non-repudiation. Together they form
| >>>>>>>>the foundation for secure Web Services.
| >>>>>>>>
| >>>>>>>>
| >>>>>>>>
| >>>>>>>The above text is NOT a requirement at all!!!
| >>>>>>>It doesn't even read like one.
| >>>>>>>It's a lite intro for D-AR006.1 thru D-AR006.6.
| >>>>>>>The editors inserted D-AR006.10 and D-AR006.11 in
| >>>>>>>the wrong place. The two should have followed
| D-AR009; and the
| >>>>>>>intro should not have been bulletized. What a mess. sigh.
| >>>>>>>
| >>>>>>>D-AR006.11 text should read as follows:
| >>>>>>>
| >>>>>>>D-AR006.11 The architecture must provide an interface for Web
| >>>>>>>Services to directly communicate with their underlying
| >>>>>>>infrastructure.
| >>>>>>>
| >>>>>>>The interface is for negotiating services that an
| infrastructure
| >>>>>>>may provide to, or perform on behalf of, requesting Web
| >>>>>>>
| >>Services.
| >>
| >>>>>>>Such value-added services may include: security, content
| >>>>>>>
| >>>>>>>
| >>>>delivery,
| >>>>
| >>>>
| >>>>>>>QoS, etc. For instance, a Web service may instruct (via the
| >>>>>>>interface)
| >>>>>>>the security agents of its infrastructure to defend against
| >>>>>>>DOS/DDOS attacks on its behalf."
| >>>>>>>
| >>>>>>>
| >>>>>>>
| >>>>>>>
| >>>>>>>>is actually a separate requirement from D-AR006.11 and should
| >>>>>>>>have been
| >>>>>>>>labeled D-AR006.12 in the document. Am I reading this
| >>>>>>>>correctly? If so,
| >>>>>>>>then this needs to be fed to the editors as a comment so
| >>>>>>>>
| >>>>>>>>
| >>>>>>>>
| >>>>>>that it is
| >>>>>>
| >>>>>>
| >>>>>>
| >>>>>>>>certain to be tracked (and fixed in the next editor's draft).
| >>>>>>>>
| >>>>>>>>The question I have then is whether or not Joe is accepting
| >>>>>>>>Ayse's request to add Auditing to this list of 6 aspects or
| >>>>>>>>whether he is suggesting that yet another requirement
| >>>>>>>>(D-AR006.13) be created to accomodate Auditing... do
| any others
| >>>>>>>>have an opinion on this?
| >>>>>>>>
| >>>>>>>>
| >>>>>>>>
| >>>>>>>I think Ayse has already backed out on Auditing.
| >>>>>>>So it's no longer an issue whether I'd accept it.
| >>>>>>>(I wasn't inclined to accept it because there's no
| threat model
| >>>>>>>that's uniquely associated with Auditing. But I
| wouldn't decide
| >>>>>>>one way or the other without hearing the case out first.)
| >>>>>>>
| >>>>>>>Whoever wants to give it another shot is welcome to present
| >>>>>>>his/her *reasoning and analysis*.
| >>>>>>>
| >>>>>>>Cheers,
| >>>>>>>
| >>>>>>>Joe Hui
| >>>>>>>Exodus, a Cable & Wireless service
| >>>>>>>==================================================
| >>>>>>>
| >>>>>>>
| >>>>>>>
| >>>>>>>>Thanks,
| >>>>>>>>
| >>>>>>>>Chris
| >>>>>>>>
| >>>>>>>>Joseph Hui wrote:
| >>>>>>>>
| >>>>>>>>
| >>>>>>>>
| >>>>>>>>
| >>>>>>>>>>From: Dilber, Ayse, ALASO [ mailto:adilber@att.com
<mailto:adilber@att.com> ]
| >>>>>>>>>>
| >>>>>>>>>>
| >>>>>>>>>>
| >>>>>>>>>>
| >>>>>>>>>[snip]
| >>>>>>>>>
| >>>>>>>>>
| >>>>>>>>>
| >>>>>>>>>
| >>>>>>>>>
| >>>>>>>>>>D-AR006.11 the six aspects need to be replaced with the
| >>>>>>>>>>following seven aspects of the security framework:
| >>>>>>>>>>
| >>>>>>>>>>
| >>>>>>>>>>
| >>>>>>>>>>
| >>>>>>>>>Ayse, the D-AR006.11 number was taken.
| >>>>>>>>>You may want to re-number your proposal as
| D-AR006.12 instead
| >>>>>>>>>if you're serious about it (to be voted on or debated).
| >>>>>>>>>
| >>>>>>>>>
| >>>>>>>>>
| >>>>>>>>>
| >>>>>>>>>
| >>>>>>>>>>Auditing;
| >>>>>>>>>>
| >>>>>>>>>>
| >>>>>>>>>>
| >>>>>>>>>>
| >>>>>>>>>Auditing* as a security aspect?
| >>>>>>>>>Can you explain why? E.g. for starter, how would you
| >>>>>>>>>characterize the threat (model) that's unique to
| Auditing? Note
| >>>>>>>>>that the impetus for requiring each of the original
| six begins
| >>>>>>>>>with a unique threat, or in some cases, threats.
| >>>>>>>>>
| >>>>>>>>>
| >>>>>>>>>
| >>>>>>>>>
| >>>>>>>>>
| >>>>>>>>>>Authentication (includes identification and authorization);
| >>>>>>>>>>
| >>>>>>>>>>
| >>>>>>>>>>
| >>>>>>>>>>
| >>>>>>>>>Authc & Authz are separate sec aspects.
| >>>>>>>>>
| >>>>>>>>>Example 1: The security policy of the very system
| that you're
| >>>>>>>>>using probably includes only Authz but not Authc.
| To login,
| >>>>>>>>>you simply enter user name and password, the system
| checks the
| >>>>>>>>>password file and lets you in. You are not asked to
| >>>>>>>>>authenticate yourself as Ayse. BTW, password file
| is known to
| >>>>>>>>>be one form of Access Control List (ACL).
| >>>>>>>>>
| >>>>>>>>>Example 2: Alice's security policy includes Authc &
| Authz. To
| >>>>>>>>>join Alice's party, Bob must present a certificate
| to Alice to
| >>>>>>>>>authenticate himself as Bob -- Authc, AND, after successful
| >>>>>>>>>authc (sometimes aka positive identification), Alice checks
| >>>>>>>>>whether Bob is on her guest list (i.e. ACL) before
| allowing him
| >>>>>>>>>into her party.
| >>>>>>>>>
| >>>>>>>>>
| >>>>>>>>>
| >>>>>>>>>
| >>>>>>>>>
| >>>>>>>>>>Access Control (file permission, etc.);
| >>>>>>>>>>
| >>>>>>>>>>
| >>>>>>>>>>
| >>>>>>>>>>
| >>>>>>>>>Access Control is just a Authz means. (See example
| 2 above.)
| >>>>>>>>>
| >>>>>>>>>Cheers,
| >>>>>>>>>
| >>>>>>>>>Joe Hui
| >>>>>>>>>Exodus, a Cable & Wireless service
| >>>>>>>>>========================================================
| >>>>>>>>>
| >>>>>>>>>
| >>>>>>>>>
| >>>>>>>>>
| >>>>>>>>>
| >>>>>>>>>>Confidentiality;
| >>>>>>>>>>Availability; Integrity; Non-repudiation.
| >>>>>>>>>>Thanks,
| >>>>>>>>>>Ayse
| >>>>>>>>>>
| >>>>>>>>>>-----Original Message-----
| >>>>>>>>>>From: Christopher Ferris [ mailto:chris.ferris@sun.com
<mailto:chris.ferris@sun.com> ]
| >>>>>>>>>>Sent: Saturday, May 04, 2002 10:00 AM
| >>>>>>>>>>To: wsawg public
| >>>>>>>>>>Subject: D-AR006.11 discussion points
| >>>>>>>>>>
| >>>>>>>>>>
| >>>>>>>>>>SUNW: This requirement goes "inside" a web service
| and places
| >>>>>>>>>>requirements
| >>>>>>>>>>on how it is designed. We should be focusing on
| externally
| >>>>>>>>>>
| >>>>>>>>>>
| >>>>>>>>>>
| >>>>>>>>observable
| >>>>>>>>
| >>>>>>>>
| >>>>>>>>
| >>>>>>>>>>(through the web service interfaces) behaviour
| >>>>>>>>>>
| >>>>>>>>>>SYBS: Implementation details. Don't seem to fit in Web
| >>>>>>>>>>Services Architecture
| >>>>>>>>>>group..
| >>>>>>>>>>
| >>>>>>>>>>W3C: See
| >>>>>>>>>>
| >>>>>>>>>>
| >>>>>>>>>>
| >>>>>>> http://lists.w3.org/Archives/Public/www-ws-arch/2002Ma
<http://lists.w3.org/Archives/Public/www-ws-arch/2002Ma>
| y/0015.html
| >>>>>>>
| >>>>>>>
| >>>>>>>
| >>>>>>>>>ORCL: I don't quite see how "an architecture" can actually
| >>>>>>>>>
| >>>>>>>>>
| >>>>>>>>>
| >>>>>>>provide an
| >>>>>>>
| >>>>>>>
| >>>>>>>
| >>>>>>>>>interface. And in this case the goal may be too ambitious
| >>>>>>>>>
| >>>>>>>>>
| >>>>>>>>>
| >>>>>>given the
| >>>>>>
| >>>>>>
| >>>>>>
| >>>>>>>>>number of different possible "infrastructures".
| >>>>>>>>>
| >>>>>>>>>PF: I just don't see the need for this.
| >>>>>>>>>
| >>>>>>>>>TIB: not clear to me that individual Web services would
| >>>>>>>>>
| >>>>>>>>>
| >>>>>>>>>
| >>>>>>ever want to
| >>>>>>
| >>>>>>
| >>>>>>
| >>>>>>>>>know whether they were under DOS at some lower layer
| >>>>>>>>>
| >>>>>>>>>CrossWeave: Don't understand this
| >>>>>>>>>
| >>>>>>>>>CMPQ: The interface is for negotiating services that an
| >>>>>>>>>infrastructure may
| >>>>>>>>>provide to, or perform on behalf of, a requesting
| Web Services.
| >>>>>>>>>Such value-added services may include: security, content
| >>>>>>>>>
| >>>>>>>>>
| >>>>delivery,
| >>>>
| >>>>
| >>>>>>>>>QoS, etc. For instance, a Web service may instruct (via the
| >>>>>>>>>interface) the security
| >>>>>>>>>agents of its infrastructure to defend against DOS/DDOS
| >>>>>>>>>attacks on its behalf.
| >>>>>>>>>
| >>>>>>>>>This seems to say that the requirement is
| >>>>>>>>>"The security framework must provide for negotiations
| >>>>>>>>>
| >>>>>>>>>
| >>>>>>>>>
| >>>>>>pertaining to
| >>>>>>
| >>>>>>
| >>>>>>
| >>>>>>>>>security considerations."
| >>>>>>>>>
| >>>>>>>>>That is, the requirement is for negotiation support; within
| >>>>>>>>>security context,
| >>>>>>>>>it is security negotiation, within QoS context, it is QoS
| >>>>>>>>>negotiation, etc.
| >>>>>>>>>
| >>>>>>>>>
| >>>>>>>>>
| >>>>>>>>>
| >>>>>>>>>
| >>>>>>>>>
| >>>>
| >>
| >>
| >
|
|
|
|
***********Confidentiality/Limited Liability Statement***************
Have the latest business news and in depth analysis delivered to your
desktop. Subscribe to "Insights", Deloitte's fortnightly email
business bulletin . . .
http://www.deloitte.com.au/preferences/preference.asp
This message contains privileged and confidential information intended
only for the use of the addressee named above. If you are not the
intended recipient of this message, you must not disseminate, copy or
take any action in reliance on it. If you have received this message
in error, please notify Deloitte Touche Tohmatsu immediately. Any
views expressed in this message are those of the individual sender,
except where the sender specifically states them to be the views of
Deloitte.
The liability of Deloitte Touche Tohmatsu, is limited by, and to the
extent of, the Accountants' Scheme under the Professional Standards
Act 1994 (NSW).
The sender cannot guarantee that this email or any attachment to it
is free of computer viruses or other conditions which may damage or
interfere with data, hardware or software with which it might be used.
It is sent on the strict condition that the user carries out and relies
on its own procedures for ensuring that its use will not interfere with
the recipients systems and the recipient assumes all risk of use and
absolves the sender of all responsibility for any consequence of its use.
Received on Thursday, 9 May 2002 19:32:19 UTC