[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: CPA & MS (was RE: Threat assessment,some dissent RE: [ebxml-msg] security pro blem with ebXML MS)
Suresh,
I'm not sure I understand what you really want to know.
I previously said that I know of no other contract besides CPA. By that I
meant an electronic contract that specifies the agreed IT technical
configuration. Of course, there is tpaML but tpaML was just a proof of
concept that led to CPP-CPA. "Other contract + MS" would not work only
because there is no other contract. Web Services does not include a
contract; WSDL is strictly a service provider description, not an
agreement.
"CPA + other transport" is conceptually possible but we have not defined
the bindings for another transport that would replace the ebXMLBinding
subtree. The obvious possibility would be "bare SOAP".
It is perfectly reasonable for the registry spec to permit other types of
contract. They just don't exist at this time, as far as I know.
Regards,
Marty
*************************************************************************************
Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287; IBM tie line 863-7287
Notes address: Martin W Sachs/Watson/IBM
Internet address: mwsachs @ us.ibm.com
*************************************************************************************
"Damodaran, Suresh" <Suresh_Damodaran@stercomm.com> on 11/12/2001 04:09:55
PM
To: Martin W Sachs/Watson/IBM@IBMUS
cc: "'Dale Moberg'" <dmoberg@cyclonecommerce.com>, James M Galvin
<galvin@drummondgroup.com>, Christopher Ferris
<chris.ferris@sun.com>, Rich Salz <rsalz@zolera.com>,
ebxml-msg@lists.oasis-open.org
Subject: CPA & MS (was RE: Threat assessment, some dissent RE:
[ebxml-msg] security pro blem with ebXML MS)
Marty,
Thanks for responding to this question.
I have a follow-up question.
Within Registry TC, we spec'ed Registry to
work with any type of contract.
I would guess
CPA + MS
Other contract + other (non MS) transport
CPA + other (non MS) transport (is it possible?
would be the only viable combinations as per CPA spec?
In particular,
Other contract + MS
would not work (as per your statements below).
Please confirm.
Regards,
-Suresh
-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Friday, November 09, 2001 10:33 PM
To: Damodaran, Suresh
Cc: 'Dale Moberg'; James M Galvin; Christopher Ferris; Rich Salz;
ebxml-msg@lists.oasis-open.org
Subject: RE: Threat assessment, some dissent RE: [ebxml-msg] security
pro blem with ebXML MS
Suresh,
You asked "What if another type contract is used?" That might be another
can of worms but I think that we can safely put it off until version 77
since no other such contract has surfaced and Web Services hasn't yet
figured out the need for agreements. So, we are dealing with the following
cases:
CPA
Manually entered configuration information equivalent to a CPA but with
no automated assurance that what both parties enter is compatible. I
think that this is what most of us understand as the meaning of "no
CPA".
No agreement at all.
The proponents of "no agreement at all" either believe that two parties
can communicate without compatible configurations or that all the
configuration information can be carried in the message header.
Regards,
Marty
****************************************************************************
*********
Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287; IBM tie line 863-7287
Notes address: Martin W Sachs/Watson/IBM
Internet address: mwsachs @ us.ibm.com
****************************************************************************
*********
"Damodaran, Suresh" <Suresh_Damodaran@stercomm.com> on 11/09/2001 05:33:48
PM
To: "'Dale Moberg'" <dmoberg@cyclonecommerce.com>, James M Galvin
<galvin@drummondgroup.com>, Christopher Ferris
<chris.ferris@sun.com>, Rich Salz <rsalz@zolera.com>
cc: ebxml-msg@lists.oasis-open.org
Subject: RE: Threat assessment, some dissent RE: [ebxml-msg] security
pro blem with ebXML MS
Dale,
In any case, the MS spec should state clearly what
kind of security it supports and what it doesn't.
It definitely is not in the interest of anyone
to say that ebXML MS provides certain security guarantees,
when it doesn't. Possibly the security considerations
section needs a good rewrite, may be other too.
(Things like CPA will have Content-Type should be in MS spec.
However, I am not sure MS assumes the uses a CPA.
What if another type contract is used? Hope I am
not opening another can of worms:-))
I do hope this subject gets discussed at the F2F.
Regards,
-Suresh
-----Original Message-----
From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com]
Sent: Friday, November 09, 2001 12:27 PM
To: Damodaran, Suresh; James M Galvin; Christopher Ferris; Rich Salz
Cc: ebxml-msg@lists.oasis-open.org
Subject: RE: Threat assessment, some dissent RE: [ebxml-msg] security
problem with ebXML MS
Jim and Suresh,
In my earlier long message I tried to summarize:
1. what kind of threats
might be provided
2. under what transport/packaging conditions
given the typical processing of
3. ebXML messages.
I considered a number of possible kinds
of threats. Apparently Jim thinks it
is only the threat of misdirection that
should be of concern. So,
for that threat, these considerations still
stand:
1. ebXML messaging processing does
not need to trust internal MIME content-type
values.
2. content-id values, if changed, will almost
certainly lead to an error condition when
they are used as part of XMLDsig signatures.
3. CPA based agreements can be used to:
a. check that internal mime content-types
are as expected. MIME error can be thrown
if enforced.
b. add digital enveloping that can encrypt the entire
MIME chunk, including the headers
(using 1847 security packaging if you like, Jim!)
Given all of this existing apparatus permitting
strong counters for the situation of MITM header
tweaking, if you still wish to mandate an
additional new security mechanism, I urged you
to hold off until the next iteration. By then,
maybe XMLEncryption will be stable or other
security proposals may have emerged that can
be cited. Maybe a tweak to the mid: or cid: URIs
that would permit mid: sub-segments-- who knows?
ebXML messaging is IMO not primarily engaged in
inventing new security solutions and countermeasures,
but instead is involved in adopting
existing stable solutions to achieve
an acceptable coverage for the standard threats
(spoofing, alteration, and sniffing).
I would rather retrofit to a dedicated
security groups carefully examined spec.
than try to throw something together at the last minute
(and we are at the last minute for 1.1).
Dale
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC