submitted on behalf of Igor Balabine....... CPA and overrides

[Maryann Hondo <mhondo@us.ibm.com>]

---------------------- Forwarded by Maryann Hondo/Austin/IBM on 02/26/2001
09:48 AM ---------------------------

"Balabine, Igor" <IBalabine@netfish.com> on 02/23/2001 09:47:29 PM

To:   "'Maryann Hondo '" <mhondo@us.ibm.com>
cc:
Subject:  Please help: CPA and overrides



Maryann,

Following is a message I sent to the ebxml-transport@lists.ebxml.org list
with my comments on the "CPA and overrides" discussion. My message was
bounced by the list: it looks like that I do not have the privilege to
submit messages to this list. What should I do to obtain such privilege?
Could you post my comment for me in the meanwhile?

Thanks in advance.

-Igor

****** MY POSTING

I do not think that there is any difference between having multiple or a
single way of doing things as long as the accepting party is able to
enforce
its own security policies for this interaction. This is a safe and secure
approach since it does not violate local security policies. This approach
also solves the "override" problem: the accepting party simply discards the
messages that do not follow the CPA guidelines.

When it comes to changing the "to" and "from" fields (as in Maryann's
example) the receiving party should state in the CPA that the message must
be properly protected ("signed") by the sender. This measure prevents third
parties from tempering with the message and allows to enforce the message
integrity.

In other words security should be enforced rather than being a bona fide
property.

-Igor

****** END OF MY POSTING



-----Original Message-----
From: christopher ferris
To: maw2@daimlerchrysler.com
Cc: Maryann Hondo; ebxml-transport@lists.ebxml.org
Sent: 2/23/01 8:45 AM
Subject: Re: CPA and overrides

Martha,

Whether a CPA details one way, or multiple ways of doing
things is irrelevant. If the automotive industry does
indeed have only a single approach, then construction of a
CPA is as simple as filling in only a very few details
that apply only to the two parties:
     party deails URL
     endpoint info (URL)
     certificates (if certificate-based security is used)

The rest could be a template that defines the specifics
that all parties (or the automotive indistry) have agreed
upon.

Seems to me that this is then a trivial price to pay
for interoperability.

Please do keep in mind that a CPA is NOT a TPA. It is
a shared configuration file that can help to ensure that
two parties can interoperably exchange business information.

Cheers,

Chris


maw2@daimlerchrysler.com wrote:
>
> For automotives and security, we pick one way to do things and it
typically
> does not change.
>
> It seems that the level of override would be an implementation issued
> agreed to between the partners.The 'to' and 'from' typically wouldn't
> change. The protocol absolutely could.
>
> With regard to the liability, it would be with the sender of the data.
>
> Martha
>
> Maryann Hondo <mhondo@us.ibm.com> on 02/23/2001 09:17:28 AM
>
> To:   Dick Brooks <dick@8760.com>
> 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
 <<Card for christopher ferris>>