RE: CPA and overrides

["Burdett, David" <david.burdett@commerceone.com>]

If a message is not digitally signed or the source of the message cannot be
determined by some other means (e.g. client side certificates on SSL), then
there NO SECURITY. It is then up to a recipient of a message to determine
whether or not to respond to a message depending on the risks. Remember it
is quite possible to have a message that needs to be sent reliably, but does
not need to be sent securely - it's up to the business process designer to
decide.

However if the message is secure, then the origin of the message is known
and therefore the values in the message can be checked for acceptability
against whatever parameters the recipient choses to use. If the recipient
does not like the message, then they can always reject the message or choose
not to respond.

I agree with Rik, there is no absolute solution to security and you have to
let people use the capabilities that are there and take due care to check
that a message has not been tampered with if that is a concern.

David

-----Original Message-----
From: Rik Drummond [mailto:rvd2@worldnet.att.net]
Sent: Saturday, February 24, 2001 5:56 AM
To: Maryann Hondo; Dick Brooks
Cc: rsalz@CaveoSystems.com; ebxml-transport@lists.ebxml.org;
maw2@daimlerchrysler.com
Subject: RE: CPA and overrides


security of the exchange is not our responsibility. our responsibility is to
offer secure mechanisms and if the user community does not use them then
that is their problem..... rik

-----Original Message-----
From: Maryann Hondo [mailto:mhondo@us.ibm.com]
Sent: Friday, February 23, 2001 8:17 AM
To: Dick Brooks
Cc: rsalz@CaveoSystems.com; ebxml-transport@lists.ebxml.org;
maw2@daimlerchrysler.com
Subject: RE: CPA and overrides


Am I the only one who is concerned about this from a security view?
if we allow for "overrides" .....what is the model of who overrides what?
can i override the "to" part or the "from" part (particularly if i want to
muck up the works of my
competition a bit) can i "override" the https protocol with http? and what
about "intermediaries"?
are they allowed to "override" things?

how does as2 provide for this type of override? is this ok? is it up to the
receiving
app to determine if the transaction came over a secure channel?  whose
liability is it
if the sender sends data over an insecure link when a secure link was
agreed to and
some information is "stolen"? are these issues addressed in as2?

i could see defining a default which is used instead of a cpp/cpa or if
there is no cpa referenced,
but i would want to know how the security piece was agreed to by both
parties and how it is possible to
verify that the correct mechanism was used.

 Maryann


Dick Brooks <dick@8760.com> on 02/23/2001 08:44:19 AM

To:   rsalz@CaveoSystems.com, ebxml-transport@lists.ebxml.org,
      maw2@daimlerchrysler.com
cc:
Subject:  RE: CPA and overrides



I agree with Martha and Rich. Forcing a CPA/CPP module onto an MSH solution
is an unnecessary burden on those
needing simple, "direct" file transfer over a single transport, which is
the
majority of implementations
in the Energy industry. The EDIINT AS2 specification made provisions for
multiple transport options by adding
a "receipt-delivery-option" header.  This header contains a URI indicating
the transport and delivery point (e.g.
http://b2b.imacompany.com/cgi-bin/ebxmlhandler or
mailto:ebxmlhandler@imacompany.com ) to send an asynchronous receipt
(acknowledgement).

CPA/CPP functionality is a nice feature for some, but it shouldn't be a
requirement for ALL. If alternate delivery channels are needed for
*acknowledgements* then I suggest a solution like that found in AS2.

Dick Brooks
http://www.8760.com/


-----Original Message-----
From: rsalz@CaveoSystems.com [mailto:rsalz@CaveoSystems.com]
Sent: Friday, February 23, 2001 7:57 AM
To: ebxml-transport@lists.ebxml.org; maw2@daimlerchrysler.com
Subject: Re: CPA and overrides


List-Unsubscribe:
 <mailto:ebxml-transport-request@lists.ebxml.org?body=unsubscribe>
List-Archive: <http://lists.ebxml.org/archives/ebxml-transport>
List-Help: <http://lists.ebxml.org/doc/email-manage.html>,
 <mailto:ebxml-transport-request@lists.ebxml.org?body=help>

As I recall the discussion of "override" from the telecon's of a couple
of weeks ago, the concern was that an MSH not be able to change the
delivery semantics that were specified in the CPA.  For example, a
UDP-based MSH could not accept a message intended for ReliableMessaging,
but then silently use BestEffort.

*IF* we put all the delivery semantics into the ebXML message header,
then this question mostly goes away, because there is no CPA involved:
it becomes a quality of implementation issue for how the business app
tells its local MSH what semantics are required *by the business
agreements.*

Requiring an MSH to have to refer to a CPA is clearly a layering violation.

     /r$

------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org


------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org



------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org


------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org