[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Need volunteer to draft definition of reliable messaging,was RE: reliable messaging - hop by hop
David F/Marty/Dan/Chris I agree when Marty said in an earlier email ... "... this is another example of why we need to clearly articulate, in the spec, what reliable messaging claims to do and what assumptions are made on the implementation." To make progress we need a volunteer to draft these statements and agree them. As far as scope is concerned, I agree with David F. We need to keep the signed Delivery Receipt as a method of doing NRR at the messaging level but not preclude receipts being generated at the application level. David F/Marty/Dan/Chris (or anyone else) will you volunteer to draft the words? David -----Original Message----- From: David Fischer [mailto:david@drummondgroup.com] Sent: Wednesday, August 29, 2001 12:38 PM To: Dan Weinreb Cc: chris.ferris@east.sun.com; ebxml-cppa@lists.oasis-open.org; ebxml-msg@lists.oasis-open.org Subject: RE: reliable messaging - hop by hop I don't mean to say there cannot be another business process which provides a Business Delivery Receipt and signs it. However, that has nothing to do with NRR. NRR is only a receipt that the message was delivered intact. This is a requirement we cannot lose track of. The idea of a Business Process Receipt stating that the application got the message and is processing (or something of that nature) is a different requirement and is outside the scope of TRP. That would be another message with another MessageId which also could be sent with a DR request and NRR. The legal ramification of a NRR is the same as Registered Mail. If the IRS says I didn't send my tax form and they are going to charge me a late fee, then I hand my signed receipt to a Judge and say "Oh yes I did and here's the proof" -- I win. That has nothing at all to do with whether my tax form is filled out correctly or even looked at it. All it proves it that they got it on time. NRR has nothing to do with the business process. This is not signing a legal document. NRR is non-repudiation OF RECEIPT. I looked in RFC2459 and I didn't see Non-Repudiation of Receipt at all. I did see Non-Repudiation and the action it refers to is in this case *receipt of the message*. NRR belongs in the MSH. Time sensitive documents need NRR even more. The Receiver can say *you never sent me the contract* and the Sender can say *Oh yes I did, you just didn't process it in time* which in a law suit is precisely what the Sender needs. How else would the Sender prove they had taken the required action? Without NRR, the Receiver has all the power since he can just ignore anything he doesn't like and later say they never received the document. This is precisely why NRR at the MSH level is critical. The idea of the MSH not having access to a key is not worth discussing. Secretaries sign for FedEx packages every day. Systems receive EDI payloads and sign receipts every day without ever looking at the payload itself. Let's stay on topic. Regards, David Fischer Drummond Group. -----Original Message----- From: Dan Weinreb [mailto:dlw@exceloncorp.com] Sent: Wednesday, August 29, 2001 1:53 PM To: david@drummondgroup.com Cc: chris.ferris@east.sun.com; ebxml-cppa@lists.oasis-open.org; ebxml-msg@lists.oasis-open.org Subject: Re: reliable messaging - hop by hop Date: Wed, 29 Aug 2001 10:51:43 -0500 From: David Fischer <david@drummondgroup.com> If there is no change then the message arrived and did not change. There is no application process here. If this is application specific then so is the signature process. I think that's exactly what Chris was getting at. The meaning of "arrived" is that it got as far as the entity that has access to the private key. The question is whether the sender should interpret that to mean "it got to the To Party MSH" or "it got to the To Party application". One concrete question: suppose the message is delivered to the To Party MSH at time T1, and gets stored persistently in the To Party MSH's queue of received messages. Then, at a later time T2, the message's time-to-live expires. Then, at a later time T3, a To Party application application requests an incoming message, and the MSH replies that there isn't any message. Under these circumstances, is it right for the From Party to have a signed NRR? NRR is analogous to pasting a PO Registered receipt on the outside of a package and having the other end sign. It is slightly better because it ensures that the original contents have not changed. This has nothing to do with application processing. In the analogy, the important question is: what good does it do the sender to have the signed registered-mail receipt? What can I, the sender, do with that receipt? What assertion about the real world am I trying to prove when I brandish the receipt in front of the judge during the trial? Legally, "non-repudiation" traditionally refers to the signing of a document: the alleged signer may want to repudiate the signature, claiming that it is a forgery or was made under undue influence. So when the To Party performs the digital signature operation that creates the NRR, what does that mean legally? In particular, does it mean "I promise that I took a look at this message"? If so, is it useful for a From Party to be able to assert that the To Party took a look at his message, even though the To Party might not have done anything about the message? In 1998, the Australian Federal Government's Electronic Commerce Expert Group adopted a technical meaning in its report to the Australian Federal Attorney General, by defining "Non-repudiation" as follows: Non-repudiation is a property achieved through cryptographic methods which prevents an individual or entity from denying having performed a particular action related to data (such as mechanisms for non-rejection or authority (origin); for proof of obligation, intent, or commitment; or for proof of ownership). RFC2459 uses this language: ...when the subject public key is used to verify digital signatures used to provide a non-repudiation service which protects against the signing entity falsely denying some action... In both cases, what "action" are we talking about? This is what defines the real semantics of the NRR. ---------------------------------------------------------------- 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