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

[Martin W Sachs <mwsachs@us.ibm.com>]

re-sending due to addressing error.

*************************************************************************************

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
*************************************************************************************
---------------------- Forwarded by Martin W Sachs/Watson/IBM on 09/05/2001
02:40 AM ---------------------------

Martin W Sachs
09/05/2001 02:05 AM

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-cppa@oasis-open.org>, <ebtwg@lists.ebtwg.org>
From: Martin W Sachs/Watson/IBM@IBMUS
Subject:  Re: T2 Non repudiation and MSG, CPP/A, BPSS spec alignment
      (Document link: Martin W. Sachs)

Arvola,

Some comments below.

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 09/04/2001 12:36:53 PM

To:   Martin W Sachs/Watson/IBM@IBMUS
cc:   "christopher ferris" <chris.ferris@east.sun.com>, "Duane Nickull"
      <duane@xmlglobal.com>, <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



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?

MWS:  I agree that if the Registry's (or any application's)
interface requirement is that in a request, the client must
provide a URL for the response message, then the client does not
have to supply a return URL ahead of time.

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.

MWS:  I believe that the element in question is intended for MSH
to MSH communication.  I don't see why it would not be able to be
used in an application-level message to specify a destination
application-level response message.  However I would want to see that
explicitly stated in the MS spec.  I have made a similar suggestion
regarding refToMessageId in application-level messages but I don't
sense acceptance of this suggestion thus far.

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.

MWS:  I could accept this point but I would not want to see the
practice used as a catch-all for eliminating information from the CPA that
should be there.

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