RE: [ebxml-cppa] CPPA teleconference minutes: October 18, 2001

[David Fischer <david@drummondgroup.com>]

Hi Tony,

<<comments in-line>>

Regards,

David.

-----Original Message-----
From: Tony Weida [mailto:rweida@hotmail.com]
Sent: Sunday, October 21, 2001 8:05 PM
To: David Fischer; CPPA
Subject: Re: [ebxml-cppa] CPPA teleconference minutes: October 18, 2001


David,

I've embedded a couple comments below, prefixed with my initials.

Cheers,
Tony

----- Original Message -----
From: David Fischer
To: CPPA
Sent: Sunday, October 21, 2001 6:32 PM
Subject: RE: [ebxml-cppa] CPPA teleconference minutes: October 18, 2001


Sorry I missed the meeting, it didn't make it onto my calendar.

Comments:

If end-to-end, signed Acknowledgment is requested, it provides NRR -- in the
same way DeliveryReceipt does.  NRR cannot be provided at the
BPSS/Application level since MSH does not pass the entire message and thus
the Application cannot generate the required Digest(s).

TW: That seems like a strong statement.  Signing the entire message is
sufficient, but is it always necessary?  I understand that messaging
elements may convey information relevant for non-repudiation, e.g., a
timestamp.  Such information may also appear in a particular type of
business payload.

<<In order for NRR to work, it must EXACTLY match the original signature
digests -- which includes the MSH headers.  Since the Application doesn't have
those headers, it cannot generate those digests.  This does not mean that the
Application might not do something similar with only the payload.  Messaging
does not stipulate what can be in the payload.  If the Application wants to do
something like sign/encrypt the payload prior to passing to the MSH, it can.
However, this is not NRR.  This is more like some subset of the original
digests/ds:Signature, so the original signature will not match.  In any case,
the Application can do whatever it likes and the MSH will provide NRR, if a
signed Acknowledgment is requested.>>


Since the MSH does not do any application parsing, any Business Level
receipts cannot be done at the MSH level.  While the Application cannot do
NRR, it can/must provide anything along the lines of "Message verified/being
processed" (i.e. Delivery Receipt).  The Application would pass this signal
to the MSH with a flag which says "sign this".  While it would not be
illegal for the Application to send a signed/encrypted payload to the MSH
(would this be S/MIME?), it is not within our model to do so.

TW: I expect that some security-sensitive applications will call for
transmitting encrypted content between authorized persons or applications,
not just between their respective MSHs.  The latter is more likely to
compromise security, for example by exposing confidential information to
unauthorized persons within an enterprise.

<<Not a problem!  The Application may pass anything it wishes to the MSH.>>

An Acknowledgment can be requested separately from Reliable Messaging
although the only difference is duplicateElimination.

I think/agree that MSH signals should be returned synchronously for HTTP.
This should be the default.  Maybe we don't need a flag, just make this a
requirement (Why would this ever be done asynchronously for HTTP?)  I think
I agree with Dale.  This should match the transport method (sync for HTTP,
async for SMTP) and should not change per message.

Regards,

David Fischer
Drummond Group.

-----Original Message-----
From: Tony Weida [mailto:rweida@hotmail.com]
Sent: Saturday, October 20, 2001 5:05 PM
To: CPPA
Subject: [ebxml-cppa] CPPA teleconference minutes: October 18, 2001


Draft minutes of the October 18 teleconference are attached.  Please send me
any additions or corrections.

Cheers,
Tony Weida
Independent CPPA Fan :-)