Re: T2 Non repudiation and MSG, CPP/A, BPSS spec alignment

[Arvola Chan <arvola@tibco.com>]

Marty:

I agree with you that if the CPA template is missing communication
endpoint information, then the missing information may have to be
filled in by the parties through other configuration means before B2B
exchange can take place. The sender must know the receiver's URL
in order to send a message. The receiver, on the other hand, may
not necessarily have to know the sender's return URL ahead of
time. An implementation may want to provide this level of flexibility
to improve scalability. For example, the ebXML registry grants
read access to all clients. Why is it important for it to know a priori
the communication URL of every client?

The existing Messaging Service spec allows for supplementing
endpoint information that is missing from the CPA. Consider the
Sender element (under TraceHeader) described in section 8.5.2.1
(line 990):

8.5.2.1.2 Location element 1001
This element contains the URL of the Sender’s Message Service Handler.
Unless there is another URL 1002
identified within the CPA or in MessageHeader (section 8.4.2), the recipient
of the message uses the 1003
URL to send a message, when required that: 1004
· responds to an earlier message 1005
· acknowledges an earlier message 1006
· reports an error in an earlier message. 1007

This element seems usable by the sender to inform the receiver of its
return URL, when the CPA installed at the receiver does not spell
out the sender's communication URL.

I am not advocating adding new elements to the message header at
this point solely to enable a CPA template to be substituted for a
complete CPA. However, I don't think we should remove
mechanisms that are already in place in the message header (either
in the PartyID under the From element, or in the Location under Sender
in the TraceHeader element) to supplement information that may
be missing from the CPA.

Regards,
-Arvola

-----Original Message-----
From: Martin W Sachs <mwsachs@us.ibm.com>
To: Arvola Chan <arvola@tibco.com>
Cc: christopher ferris <chris.ferris@east.sun.com>; Duane Nickull
<duane@xmlglobal.com>; ebxml-msg@oasis-open.org <ebxml-msg@oasis-open.org>;
ebxml-cppa@oasis-open.org <ebxml-cppa@oasis-open.org>; ebtwg@lists.ebtwg.org
<ebtwg@lists.ebtwg.org>
Date: Sunday, September 02, 2001 10:12 PM
Subject: Re: T2 Non repudiation and MSG, CPP/A, BPSS spec alignment


>
>Arvola,
>
>As you state, a CPA template is missing information.  Therefore it shall
>not be used as the sole configuration information for a pair of trading
>partners.  If a CPA template is installed as configuration information, the
>missing information must be filled in by each party (per agreement with the
>other party) before B2B exchanges can begin.
>
>We must not add elements to the message header solely to enable a CPA
>template to be substituted for a complete CPA.
>
>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
>***************************************************************************
**********
>
>
>
>Arvola Chan <arvola@tibco.com> on 08/30/2001 03:06:51 PM
>
>To:   christopher ferris <chris.ferris@east.sun.com>, Duane Nickull
>      <duane@xmlglobal.com>
>cc:   ebxml-msg@oasis-open.org, ebxml-cppa@oasis-open.org,
>      ebtwg@lists.ebtwg.org
>Subject:  Re: T2 Non repudiation and MSG, CPP/A, BPSS spec alignment
>
>
>
>Chris:
>
>When the Messaging Service is used in conjunction with some
>CPA template, rather than a bilateral CPA, then endpoint
>information may not be available and has to be explicitly
>supplied in the message header.
>
>I would recommend that the To Party MSH not be obligated
>to report security errors back to the From Party MSH. The
>former should have the option of just logging the securty
>error internally and then silently dropping the message.
>
>-Arvola
>
>-----Original Message-----
>From: christopher ferris <chris.ferris@east.sun.com>
>To: Duane Nickull <duane@xmlglobal.com>
>Cc: Arvola Chan <arvola@tibco.com>; ebxml-msg@oasis-open.org
><ebxml-msg@oasis-open.org>; ebxml-cppa@oasis-open.org
><ebxml-cppa@oasis-open.org>; ebtwg@lists.ebtwg.org <ebtwg@lists.ebtwg.org>
>Date: Thursday, August 30, 2001 11:48 AM
>Subject: Re: T2 Non repudiation and MSG, CPP/A, BPSS spec alignment
>
>
>>Yes, I raised this issue in Brussels when we were considering
>>inclusion of a responseTo and/or errorsTo URL in the message
>>header. An attacker could potentially send a message that had
>>an intentional error forcing the receiving MSH to respond to the
>>URL in the errorsTo element.
>>
>>One of the reasons that a CPA (or an equivalent set of information)
>>is so valuable is that the return address(es) are established by
>>agreement. The return addresses can be vetted by both parties.
>>
>>Cheers,
>>
>>Chris
>>
>>Duane Nickull wrote:
>>>
>>> Arvola Chan wrote:
>>>
>>> > The BPSS spec says that nonRepudiationOfReceipt (NRR) is tied to the
>>> > ReceiptAcknowledgement signal. NRR and reliable messaging are
>orthogonal. A
>>> > business process may specify the non repudiation of receipt for the
>>> > requesting business activity business message and/or the repudiation
>of
>>> > receipt for the responding business activity business message, without
>>> > requiring that reliable messaging be used. I think the Messaging
>Service
>>> > should not tie NRR to the DeliveryReceipt element if the latter is
>used
>>> > exclusively in reliable messaging.<SNIP>
>>>
>>>  >>>>>>>>
>>>
>>> I want to bring up a security concern that came to mind reading all of
>>> this.  Is there any possibility that someone could place a cleverly
>>> composed message with a ReceiptAcknowledgement signal required in return
>>> to a multiple parties thereby starting a "Smurf" campaign.  Many of you
>>> who have been in the industry long enough probably remember the chaos
>>> caused by smurf attacks back in the 90's.
>>>
>>> Just a thought to muse over ;-)
>>>
>>> Duane Nickull
>>>
>>> ----------------------------------------------------------------
>>> To subscribe or unsubscribe from this elist use the subscription
>>> manager: <http://lists.ebtwg.org/ob/adm.pl>
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.ebtwg.org/ob/adm.pl>
>
>
>