[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: CPA and overrides
while it may not be transports stated responsibility, it is an implied ebxml responsibility and i just want to know where we want this to be documented.....if transport decides to allow overrides and not adhere to the cpa then the security team will need to document this in our Risk Assessment Can we(the security team) see the latest draft of the document? thanks. Maryann "Rik Drummond" <rvd2@worldnet.att.net> on 02/24/2001 08:56:26 AM To: "Maryann Hondo" <mhondo@us.ibm.com>, "Dick Brooks" <dick@8760.com> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC