OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

was message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [no subject]


Scenario -  a security researcher finds a new issue with an application =
and wants to create a signature to test for the issue in his environment =
and other peoples. He first goes to the WAS Thesaurus and from the =
textual descriptions immediatly say that this is a SQL injection issue =
and points to the reference description of SQL injection. He has =
immediatly found common concise accurate language and does not need to =
dream up the term "Database HTTP Introspection" which would confuse =
everyone;-) This is the thing we are creating in this phase. He then =
goes to the risk ranking model and is able to deduce that based on the =
the model that this is a high risk vulnerability (not to pre-empt that =
work). This is the peice we were going to create next. He then describes =
the specific technical details of the vulnerability he discovered which =
will likely include a combination of all the stuff you mention below.=20

I think your Section 2 aligns with this section of work which is where I =
think the dis-connect is. The rest is scope for the main body of work we =
are doing (the real guts of WAS) but not this peice.=20

I know there are a number of people on this list who have mailed me to =
explain that thier silence is not a fucntion of their lack of interest =
but that they are really interested in the XML Schema (ie the guts =
only).=20

So based on that I have a proposal of two ways we can work moving =
forward more effectively. If more people want Option 1we can revise the =
schedule / agenda and do this and get cracking ASAP.

Option 1
I will personally run with completing the thesaurus and risk ranking =
models over the next few weeks. This will allow the bulk of the group to =
start work on the XML schema and get under the hood. We (I) can revise =
the thesaurus work if needed as the XML portion of the project shapes =
out.

If we do this I would suggest we invite Rogan Dawes to spend some time =
on this Thursdays meeting walking through the existing VulnXML as a =
starting point.

Option 2
All plough on for the next 6 weeks with the thesaurus and risk ranking =
model as planned before tackling the XML.

I am assuming most people want to get to the WAS format ASAP so I will =
setup a vote for this to be completed before COB Tuesday.

Seem sensible ?
  ----- Original Message ----- =20
  From: Jeff Williams @ Aspect=20
  To: was@lists.oasis-open.org=20
  Sent: Saturday, August 30, 2003 8:45 AM
  Subject: Re: [was] WAS Schema first draft forwarded from Andrew =
Jaquith


  I've reviewed the schema very closely, and I'm not convinced this is =
heading the right direction. Under the proposed schema, a vulnerability =
has 5 types of information:

  Vulnerability
      - Attack Characteristics (group and subgroup -- e.g. access =
control and authorization)
      - Attack Surfaces (system boundary, component boundary, source =
code)
      - Target (application component, infrastructure component, end =
user)
      - Conditions (privilege, port)
      - Consequences (denial of service, privilege elevation, transfer =
of trust, identity impersonation, data disclosure, security requirements =
violation)

  Many of these terms are not clear to me, nor am I convinced that every =
vulnerability will have information in all of these categories.  I also =
believe that many types of useful information have no place in the =
proposed schema.

  I think our goal should be to create a language for communicating =
about web application vulnerabilities that is rich enough to express all =
the information we have about vulnerabilities, yet simple and clear =
enough for anyone to understand. In my last message, I proposed a schema =
that would look something like this:

  Vulnerability
      - Basic Characteristics
      - Security Characteristics
      - Testing Characteristics
      - Exploit Characteristics
      - Remediation Characteristics

  Each of those types of characteristics was detailed as follows:

  1 - Basic characteristics -- obvious, concrete characteristics are the =
best for unique identification and searching purposes. Some examples =
(nowhere near a complete list) I think would be useful to have =
documented for each vulnerability are:
      - The name, version of the targeted application
      - Platform info(servers, versions)
      - HTTP info(method, headers, cookies, domain, response code)
      - Parameter info (form name, field name, URL, querystring)
      - Code (language, method name, line number, error message)
      - Other common identifiers (filenames)

  2 - Security characteristics -- these will "map" vulnerabilities into =
a security space. Not as important for unique identification, but very =
useful for risk analysis and understanding. By the way, I think using =
characteristics is a cleaner way to handle the idea of 'groups':
      - Security area (confidentiality, integrity, availability, =
accountability, privacy)
      - Vulnerability category (Top Ten, Mark's list below, others -- =
this is where the thesaurus idea is best for aliases)
      - Related security mechanisms (authentication, authorization, =
encryption, filtering, logging, etc...)
      - Likelihood of exploit (tools, difficulty)
      - Consequence (defacement, disclosure, corruption, denial of =
service)

  3 - Characteristics related to how to TEST for the vulnerability --  =
these are a step away from characteristics of the vulnerability, but I =
think could be included in this model without too much difficulty. Note =
that these won't help much at all with unique identification, but will =
help the user who wants to know if they're susceptible.
      - Finding in running application (proxy mitm, scanning, tools to =
use)
      - Finding in code (search strings, patterns to look for, tools to =
use)

  4 - Characteristics related to how to EXPLOIT the vulnerability -- as =
discussed on the list, I don't think we should try to put specific =
exploit recipes in XML -- it's too hard. This is for a brief text =
description of how to exploit.  Specific exploits are best represented =
in NASL, or libwhisker perl, or something.
      - Specific tools to use
      - Methodology or process

  5 - Characteristics related to how to REMEDY the vulnerability -- I =
think these will be extremely useful if you want to find out if you've =
got a vulnerability, and if you do, to determine how to fix it.=20
      - Approaches (fix code, block requests, filter, apply patch, start =
over)
      - Forensics (how to search logs, other evidence of exploit)

  Thoughts?

  -- Jeff=20

    ----- Original Message -----=20
    From: Mark Curphey=20
    To: was@lists.oasis-open.org=20
    Sent: Tuesday, August 26, 2003 3:57 PM
    Subject: [was] WAS Schema first draft forwarded from Andrew Jaquith


    All,

    Attached below is an email and the first draft at the schema from =
Andrew Jaquith to deal with the classification / thesaurus. There is =
also a Java skunk works app using it. Andy is on the road this week and =
so unable to attend this weeks meeting. I am also unable to attend this =
weeks meeting so I am proposing we don't meet this week, have an =
additional meeting next week but still plough on over the email list. I =
know most people were waiting on this schema to get their teeth into =
things so I hope things will really get going now. Hint, hint ;-)

    I am pretty conscious of time given that in order to maintain =
schedule we really need to produce the textual document within a few =
weeks. So we need to get into this and close out on the characteristics =
and groupings this week. I will then take the lead on creating the =
documentation version of the thesaurus that we will release and we can =
move onto the risk ranking and then the guts of the WAS format.

    Andy you are a star!

    Mark

    <Andrew Jaquith>

    Mark,

    Here is the first cut at an XML schema for WAS. The schema is pretty =

    straightforward, and is taken directly from the Word doc you sent=20
    previously, plus or minus one or two minor tweaks I've made.

    I've enclosed the schema (src/schema) and a sample Java app=20
    (SerializerTester) that creates a Vulnerability object, serializes =
it to=20
    XML, and deserializes it back into an object graph. If you are =
wondering=20
    why the file is so huge, it's because I enclosed all of the Java and =

    Javadocs.

    If you want to run the Java app you will need a recent JDK (1.4.2 is =

    what I used) and the Java Web Services Developer Pack 1.2.

    Everything pretty much flows from the schema, so we can modify it at =

    will & then re-generate the Java. I've enclosed an Ant build.xml =
file=20
    that automates the build process.

    =20



-------------------------------------------------------------------------=
---


    =
---------------------------------------------------------------------
    To unsubscribe, e-mail: was-unsubscribe@lists.oasis-open.org
    For additional commands, e-mail: was-help@lists.oasis-open.org
------=_NextPart_000_01C9_01C36EDF.C29A4B80
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1226" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>After reading Jeff's mail below;</DIV>
<DIV>&nbsp;</DIV>
<DIV>I think what maybe happening here is that we delved into the world =
of XML=20
to help us create the classification scheme and it maybe confusing some =
things.=20
For a level set, this is where I think we are;</DIV>
<DIV>&nbsp;</DIV>
<DIV>1. We want to create some common langauge and high level groupings =
from=20
which to describe issues at a high "human readable non-technical =
manner". This=20
was the classification scheme.</DIV>
<DIV>2. After some debate we decided as a group that strict =
classification was=20
futile but a thesaurus approach of terms grouped by similar =
characteristics was=20
valuable with standard textual language to support it. Remember this is =
solely=20
for the purpose of someone being able to reference SQL injection as SQL=20
Injection and not describe Database sabotage as a brand new =
attack.</DIV>
<DIV>3. In order to help with our high level characteristic Andy created =
a=20
schema.</DIV>
<DIV>&nbsp;</DIV>
<DIV>From what I can read from the message below I think this is all =
valid=20
conversation if we were discussing Part Three of our proposal but is =
beyond=20
scope for this Part One "classification" piece which should really be =
*very*=20
simple. Remember this is just to support the XML format with some =
terminlogy=20
that will help people in grouping, sorting and searching for =
vulnerabilities=20
that will ultimately be created with the WAS format. </DIV>
<DIV>&nbsp;</DIV>
<DIV>Scenario - &nbsp;a security researcher finds a new issue with an=20
application and wants to create a signature to test for the issue in his =

environment and other peoples. He first goes to the WAS Thesaurus and =
from the=20
textual descriptions immediatly say that this is a SQL =
injection&nbsp;issue and=20
points to the reference&nbsp;description&nbsp;of SQL injection. He has=20
immediatly found common concise accurate language and does not need=20
to&nbsp;dream up the term "Database HTTP Introspection" which would =
confuse=20
everyone;-) This is the thing we are creating in this phase. He then =
goes to the=20
risk ranking model and is able to deduce that based on the the model =
that this=20
is a high risk vulnerability (not to pre-empt that work). This is the =
peice we=20
were going to create next. He then describes the specific technical =
details of=20
the vulnerability&nbsp;he discovered which will =
likely&nbsp;include&nbsp;a=20
combination of all the stuff you mention below. </DIV>
<DIV>&nbsp;</DIV>
<DIV>I think your Section 2 aligns with this section of work which is =
where I=20
think the dis-connect is. The rest is scope for the main body of work we =
are=20
doing (the real guts of WAS) but not this peice. </DIV>
<DIV>&nbsp;</DIV>
<DIV>I know there are a number of people on this list who have mailed me =
to=20
explain that thier silence is not a fucntion of their lack of interest =
but that=20
they are really interested in the XML Schema (ie the guts only). </DIV>
<DIV>&nbsp;</DIV>
<DIV>So based on that I have a proposal of two ways we can work moving =
forward=20
more effectively. If&nbsp;more people want Option 1we can&nbsp;revise =
the=20
schedule / agenda and do this and get cracking ASAP.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Option 1</DIV>
<DIV>I will personally&nbsp;run with completing the thesaurus and risk =
ranking=20
models over the next few weeks. This will allow the bulk of the group to =
start=20
work on the XML schema and get under the hood.&nbsp;We (I) can revise =
the=20
thesaurus work if needed as the XML portion of the project shapes =
out.</DIV>
<DIV>&nbsp;</DIV>
<DIV>If we do this I would suggest we invite Rogan Dawes to spend some =
time on=20
this Thursdays meeting walking through the existing VulnXML as a =
starting=20
point.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Option 2</DIV>
<DIV>All plough on for the next 6 weeks with the thesaurus and risk =
ranking=20
model as planned before tackling the XML.</DIV>
<DIV>&nbsp;</DIV>
<DIV>I am assuming most people want to get to the WAS format ASAP =
so&nbsp;I will=20
setup a vote for this to be completed before COB Tuesday.</DIV>
<DIV><BR>Seem sensible ?</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message -----&nbsp; =
</DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=3Djeff.williams@aspectsecurity.com=20
  href=3D"mailto:jeff.williams@aspectsecurity.com";>Jeff Williams @ =
Aspect</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=3Dwas@lists.oasis-open.org=20
  href=3D"mailto:was@lists.oasis-open.org";>was@lists.oasis-open.org</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Saturday, August 30, 2003 =
8:45=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: [was] WAS Schema =
first draft=20
  forwarded from Andrew Jaquith</DIV>
  <DIV><BR></DIV>
  <DIV>I've reviewed the schema very closely, and I'm not convinced this =
is=20
  heading the right direction.&nbsp;Under the proposed schema, a =
vulnerability=20
  has 5 types of information:</DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff>Vulnerability</FONT></DIV>
  <DIV><FONT color=3D#0000ff>&nbsp;&nbsp;&nbsp; - Attack Characteristics =
(group=20
  and subgroup -- e.g. access control and authorization)</FONT></DIV>
  <DIV><FONT color=3D#0000ff>&nbsp;&nbsp;&nbsp; - Attack Surfaces =
(system=20
  boundary, component boundary, source code)</FONT></DIV>
  <DIV><FONT color=3D#0000ff>&nbsp;&nbsp;&nbsp; - Target (application =
component,=20
  infrastructure component, end user)</FONT></DIV>
  <DIV><FONT color=3D#0000ff>&nbsp;&nbsp;&nbsp; - Conditions (privilege, =

  port)</FONT></DIV>
  <DIV><FONT color=3D#0000ff>&nbsp;&nbsp;&nbsp; - Consequences (denial =
of service,=20
  privilege elevation, transfer of trust, identity impersonation, data=20
  disclosure, security requirements violation)</FONT></DIV>
  <DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Many of these terms are not clear to me, nor am I convinced that =
every=20
  vulnerability will have information in all of these categories.&nbsp; =
I also=20
  believe that many types of useful information have&nbsp;no place in =
the=20
  proposed schema.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>I think our goal should be to create a language for communicating =
about=20
  web application vulnerabilities that is rich enough to express all the =

  information we have about vulnerabilities, yet simple and clear enough =
for=20
  anyone to understand.&nbsp;In my last message, I proposed a schema =
that would=20
  look something like this:</DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff>Vulnerability</FONT></DIV>
  <DIV><FONT color=3D#0000ff>&nbsp;&nbsp;&nbsp; - Basic=20
  Characteristics</FONT></DIV>
  <DIV><FONT color=3D#0000ff>&nbsp;&nbsp;&nbsp; - Security=20
  Characteristics</FONT></DIV>
  <DIV><FONT color=3D#0000ff>&nbsp;&nbsp;&nbsp; - Testing=20
  Characteristics</FONT></DIV>
  <DIV><FONT color=3D#0000ff>&nbsp;&nbsp;&nbsp; - Exploit=20
  Characteristics</FONT></DIV>
  <DIV><FONT color=3D#0000ff>&nbsp;&nbsp;&nbsp; - Remediation=20
  Characteristics</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Each of those types of characteristics was detailed as =
follows:</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>
  <DIV>1 - Basic characteristics -- obvious, concrete characteristics =
are the=20
  best for unique identification and searching purposes.&nbsp;Some =
examples=20
  (nowhere near a complete list) I think would be useful to have =
documented for=20
  each vulnerability are:</DIV>
  <DIV>
  <DIV>&nbsp;&nbsp;&nbsp; - The name, version&nbsp;of the targeted=20
  application</DIV>
  <DIV>&nbsp;&nbsp;&nbsp; - Platform info(servers,=20
  versions)</DIV>&nbsp;&nbsp;&nbsp; - HTTP info(method, headers, =
cookies,=20
  domain, response code)</DIV>
  <DIV>&nbsp;&nbsp;&nbsp; - Parameter info (form name, field name, URL,=20
  querystring)</DIV>
  <DIV>&nbsp;&nbsp;&nbsp; - Code (language, method name, line number, =
error=20
  message)</DIV>
  <DIV>&nbsp;&nbsp;&nbsp; - Other common identifiers (filenames)</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>2 -&nbsp;Security characteristics&nbsp;-- these will "map"=20
  vulnerabilities into a security space. Not as important for unique=20
  identification, but very useful for risk analysis and understanding. =
By the=20
  way, I think using characteristics is a cleaner way to handle the idea =
of=20
  'groups':</DIV>
  <DIV>&nbsp;&nbsp;&nbsp; - Security area (confidentiality, integrity,=20
  availability, accountability, privacy)</DIV>
  <DIV>&nbsp;&nbsp;&nbsp; - Vulnerability category (Top Ten, Mark's list =
below,=20
  others -- this is where the thesaurus idea is best for aliases)</DIV>
  <DIV>
  <DIV>&nbsp;&nbsp;&nbsp; - Related security mechanisms (authentication, =

  authorization, encryption, filtering, logging, =
etc...)</DIV>&nbsp;&nbsp;&nbsp;=20
  - Likelihood of exploit (tools, difficulty)</DIV>
  <DIV>&nbsp;&nbsp;&nbsp; - Consequence (defacement, disclosure, =
corruption,=20
  denial of service)</DIV>
  <DIV>
  <DIV>&nbsp;</DIV>
  <DIV>3 - Characteristics related to how to TEST for the vulnerability =
--&nbsp;=20
  these are a step away from characteristics of the vulnerability, but I =
think=20
  could be included in this model without too much difficulty. Note that =
these=20
  won't help much at all with unique identification, but will help the =
user who=20
  wants to know if they're susceptible.</DIV>
  <DIV>&nbsp;&nbsp;&nbsp; - Finding in running application (proxy mitm,=20
  scanning, tools to use)</DIV>
  <DIV>&nbsp;&nbsp;&nbsp; - Finding in code (search strings, patterns to =
look=20
  for, tools to use)</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>4 - Characteristics related to how to EXPLOIT the vulnerability =
-- as=20
  discussed on the list, I don't think we should try to put specific =
exploit=20
  recipes in XML -- it's too hard. This is for a brief text description =
of how=20
  to exploit.&nbsp; Specific exploits are best represented in NASL, or=20
  libwhisker perl, or something.</DIV>
  <DIV>&nbsp;&nbsp;&nbsp;&nbsp;- Specific tools to use</DIV>
  <DIV>&nbsp;&nbsp;&nbsp; - Methodology or process</DIV>
  <DIV>
  <DIV>&nbsp;</DIV>
  <DIV>5 - Characteristics related to how to REMEDY the vulnerability -- =
I think=20
  these will be extremely useful if you want to find out if you've got a =

  vulnerability, and if you do, to determine how to fix it. </DIV>
  <DIV>&nbsp;&nbsp;&nbsp; - Approaches (fix code, block requests, =
filter, apply=20
  patch, start over)</DIV>
  <DIV>&nbsp;&nbsp;&nbsp; - Forensics (how to search logs, other =
evidence of=20
  exploit)</DIV>
  <DIV>&nbsp;</DIV></DIV></DIV></DIV>
  <DIV>Thoughts?</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>--=20
  <STYLE type=3Dtext/css>
		<!--
		body { FONT-Size: 10pt; FONT-Family: 'Arial'; FONT-Weight: normal; }
		.small { FONT-Size: 9pt; FONT-Family: 'Arial'; FONT-Weight: normal; }
		-->

=09
	</STYLE>
  Jeff </DIV>
  <DIV>&nbsp;</DIV></DIV>
  <BLOCKQUOTE=20
  style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
    <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
    <DIV=20
    style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
    <A title=3Dmark@curphey.com href=3D"mailto:mark@curphey.com";>Mark =
Curphey</A>=20
    </DIV>
    <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=3Dwas@lists.oasis-open.org=20
    =
href=3D"mailto:was@lists.oasis-open.org";>was@lists.oasis-open.org</A> =
</DIV>
    <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, August 26, =
2003 3:57=20
    PM</DIV>
    <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> [was] WAS Schema =
first draft=20
    forwarded from Andrew Jaquith</DIV>
    <DIV><BR></DIV>All,<BR><BR>Attached below is an email and the first =
draft at=20
    the schema from Andrew Jaquith to deal with the classification / =
thesaurus.=20
    There is also a Java skunk works app using it. Andy is on the road =
this week=20
    and so unable to attend this weeks meeting. I am also unable to =
attend this=20
    weeks meeting so I am proposing we don't meet this week, have an =
additional=20
    meeting next week but still plough on over the email list. I know =
most=20
    people were waiting on this schema to get their teeth into things so =
I hope=20
    things will really get going now. Hint, hint ;-)<BR><BR>I am pretty=20
    conscious of time given that in order to maintain schedule we really =
need to=20
    produce the textual document within a few weeks. So we need to get =
into this=20
    and close out on the characteristics and groupings this week. I will =
then=20
    take the lead on creating the documentation version of the thesaurus =
that we=20
    will release and we can move onto the risk ranking and then the guts =
of the=20
    WAS format.<BR><BR>Andy you are a =
star!<BR><BR>Mark<BR><BR>&lt;Andrew=20
    Jaquith&gt;<BR><BR>Mark,<BR><BR>Here is the first cut at an XML =
schema for=20
    WAS. The schema is pretty <BR>straightforward, and is taken directly =
from=20
    the Word doc you sent <BR>previously, plus or minus one or two minor =
tweaks=20
    I've made.<BR><BR>I've enclosed the schema (src/schema) and a sample =
Java=20
    app <BR>(SerializerTester) that creates a Vulnerability object, =
serializes=20
    it to <BR>XML, and deserializes it back into an object graph. If you =
are=20
    wondering <BR>why the file is so huge, it's because I enclosed all =
of the=20
    Java and <BR>Javadocs.<BR><BR>If you want to run the Java app you =
will need=20
    a recent JDK (1.4.2 is <BR>what I used) and the Java Web Services =
Developer=20
    Pack 1.2.<BR><BR>Everything pretty much flows from the schema, so we =
can=20
    modify it at <BR>will &amp; then re-generate the Java. I've enclosed =
an Ant=20
    build.xml file <BR>that automates the build =
process.<BR><BR>&nbsp;<BR>
    <P>
    <HR>

    =
<P></P>------------------------------------------------------------------=
---<BR>To=20
    unsubscribe, e-mail: <A=20
    =
href=3D"mailto:was-unsubscribe@lists.oasis-open.org";>was-unsubscribe@list=
s.oasis-open.org</A><BR>For=20
    additional commands, e-mail: <A=20
    =
href=3D"mailto:was-help@lists.oasis-open.org";>was-help@lists.oasis-open.o=
rg</A></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_01C9_01C36EDF.C29A4B80--



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]