RE: Issue: How CPA is used in the spec

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

David,
I don't want to derail this again.
It just concerns me that you are proposing there is reliable messaging at
all if you don't even know the
authenticity of the sender, and then you're also going to arbitrarily
override whatever configuration
you supposedly agreed to with this un-identified sender

so I guess you're saying that it's no less secure to override the CPA than
to engage in business
with someone whose identity you can't verify, and indeed that is true.

My issue was not that the information was in the header, but that the
information in the header
was used to override whatever agreement the two parties established and
referenced with the CPAid
resolution without any acknowlegment or recording of this action.


Maryann

"Burdett, David" <david.burdett@commerceone.com> on 03/12/2001 01:31:32 PM

To:   "'Maryann Hondo'" <mhondo@us.ibm.com>
cc:   "'Rich Salz'" <rsalz@zolera.com>, "ebXML Transport (E-mail)"
      <ebxml-transport@lists.ebxml.org>
Subject:  RE: Issue: How CPA is used in the spec



Maryann

Perhaps I'm misunderstanding something, but as long as the authenticity of
a
sender is not verifiable (e.g. by using SSL or XMLDsig), any message is
insecure. How does putting the reliable messaging information in the header
make it less secure than putting it in the CPA.

David

-----Original Message-----
From: Maryann Hondo [mailto:mhondo@us.ibm.com]
Sent: Monday, March 12, 2001 10:06 AM
To: Burdett, David
Cc: 'Rich Salz'; ebXML Transport (E-mail)
Subject: RE: Issue: How CPA is used in the spec


David,

I do not believe that your proposed wording is adequate from a security
perspective.
I support Rich's text.

I thought that the intent is that the CPAid resolves to a set of
configuration information whether
or not it was a CPA. So, if the header elements don't match the agreed to
configuration there's
a problem.  Whether or not the receiver decides to process the request
anyway is up to them
but the behavior is undefined and potentially insecure.

Maryann

"Burdett, David" <david.burdett@commerceone.com> on 03/12/2001 12:28:53 PM

To:   "'Rich Salz'" <rsalz@zolera.com>
cc:   "ebXML Transport (E-mail)" <ebxml-transport@lists.ebxml.org>
Subject:  RE: Issue: How CPA is used in the spec



Rich

Following on from todays conference call. How about the following wording
which combines elements from both your and my wording.

>>>
The values for the reliable messaging parameters are determined by
appropriate elements from the CPA identified by the CPAid. If a receiver
determines that a message is in conflict with the specified CPA, then the
receiver MAY either:

* report the inconsistency with an errorCode of Inconsistent and a severity
of either Warning or Error, or
* use the parameters in the header to over-ride the parameters in the CPA.

If the parameters are not present in the header, then the parameter values
identified by the CPAId MUST be used if the CPAId is recognized. If the CPA
is not recognized, then report an error with an errorCode of NotRecognized
and Severity of Error.

Senders of messages SHOULD therefore only send messages containing reliable
messaging parameters if they have prior knowledge of the receiver's
behavior.
<<<


-----Original Message-----
From: Rich Salz [mailto:rsalz@zolera.com]
Sent: Friday, March 09, 2001 6:36 PM
To: Burdett, David
Cc: ebXML Transport (E-mail)
Subject: Re: Issue: How CPA is used in the spec


If only to have something to vote on for Monday ...  I think that if an
MSH gets a message that is in conflict with the CPA, the results should
be undefined.  The receiver can return an error, ignore the conflict,
accept the override, or invoke a remote HCF (halt and catch fire)
instruction on the sender.

So my suggested wording for section 8.5.3 (on the CPAId element) after
line 438 is:

"The values for the reliable messaging parameters are determined by
appropriate elements from the CPA identified by the CPAid. If a receiver
determines that a message is in conflict with the specified CPA, the
results are undefined. Therefore, senders SHOULD NOT generate such
messages unless they have prior, out-of-band knowledge about the
receiver's behavior."

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