OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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


Tony, I agree.

David.

-----Original Message-----
From: Tony Weida [mailto:rweida@hotmail.com]
Sent: Monday, October 22, 2001 10:29 AM
To: Christopher Ferris; David Fischer
Cc: CPPA
Subject: Re: [ebxml-cppa] CPPA teleconference minutes: October 18, 2001


David and Chris,

David's characterization of NRR seems to be exclusively focused on
non-repudiation of message receipt by an MSH.  I wanted to suggest an
alternative: non-repudiation of business payload receipt by a "business
application".  Giving the app access to the entire message is sufficient for
that purpose, but I don't know that it's necessary.

Tony

----- Original Message -----
From: "Christopher Ferris" <chris.ferris@sun.com>
To: "David Fischer" <david@drummondgroup.com>
Cc: "Tony Weida" <rweida@hotmail.com>; "CPPA"
<ebxml-cppa@lists.oasis-open.org>
Sent: Monday, October 22, 2001 9:39 AM
Subject: Re: [ebxml-cppa] CPPA teleconference minutes: October 18, 2001


> David,
>
> Again, you are making an assumption that the "application"
> or more specifically the NRR function doesn't have access
> to the unadulterated message contents. I think that this is
> a false assumption. The specification makes no claims whatsoever
> as to what the "application" gets, nor what form that should
> take.
>
> You also say:
>
>  > <<Not a problem!  The Application may pass anything it wishes to the
MSH.>>
>
>
> I would respond that the MSH may pass anything to the "application"
> that it wishes. We say nothing about the implementation of
> the software stack that manifests itself as an MSH + "application"
> nor should we, IMO.
>
> The MSH is an abstraction, not a technical specification for an
> implementation.
>
> Cheers,
>
> Chris
> David Fischer wrote:
>
> > 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 :-)
> >
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
> >
>
>
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC