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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

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

Subject: RE: submitted on behalf of Igor Balabine....... CPA and overrides

Let me understand...  If I (a small business man) get a multi-million dollar
PO from IBM but the security is not EXACTLY correct, I am just to discard?
This is my chance, my dream.  I am going to verify and process this
out-of-band.  I will certainly NOT discard just because a bit is out of

We have to think small.  Most businesses cannot do business like the big
guys.  They cannot be that strict, arbitrarily rejecting business documents
because they might lie just outside the rules.

David Fischer
Drummond Group

-----Original Message-----
From: Maryann Hondo [mailto:mhondo@us.ibm.com]
Sent: Monday, February 26, 2001 8:54 AM
To: ebxml-transport@lists.ebxml.org
Subject: submitted on behalf of Igor Balabine....... CPA and overrides

---------------------- 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>
Subject:  Please help: CPA and overrides


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.



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
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

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



-----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


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

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.



maw2@daimlerchrysler.com wrote:
> For automotives and security, we pick one way to do things and it
> 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
> 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
> 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
> 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
> is an unnecessary burden on those
> needing simple, "direct" file transfer over a single transport, which
> the
> majority of implementations
> in the Energy industry. The EDIINT AS2 specification made provisions
> multiple transport options by adding
> a "receipt-delivery-option" header.  This header contains a URI
> 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
> 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
> 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
> 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
>      /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>>

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

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

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC