[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-msg] Messaging Spec v1.092
I was originally objecting to the following statement on line 1557: "If the original message is not signed, the [XMLDSIG] Reference element must be derived from the original message (see section 4.1.3)." I think the use of "must" is too strong. Is it conceivable that a receiver MSH may have the policy of not returning a signed Acknowledgment unless the original message is also signed? I think it should be allowed to return an error or warning indicating an error code of Inconsistent or NotSupported. It should also be allow to comply with the signed AckRequested directive if it chooses to. Regarding Rich's comment that a service may want to sign everything it generates, an Acknowledgment message can always be signed. The issue is whether the Acknowledgment element needs to include ds:Reference elements that contain digests for the MIME parts of the original message. I don't think it is reasonable to mandate that the receiver MUST calculate the digests if they were not included in the original message in the first place. Regards, -Arvola ----- Original Message ----- From: "David Fischer" <david@drummondgroup.com> To: "Martin W Sachs" <mwsachs@us.ibm.com>; "Ralph Berwanger" <rberwanger@bTrade.com> Cc: "Christopher Ferris" <chris.ferris@sun.com>; "Arvola Chan" <arvola@tibco.com>; "ebXML Msg" <ebxml-msg@lists.oasis-open.org>; "Ian. C. Jones (E-mail)" <ian.c.jones@bt.com> Sent: Friday, January 04, 2002 8:01 AM Subject: RE: [ebxml-msg] Messaging Spec v1.092 > OK, what shall I do? > > David. > > -----Original Message----- > From: Martin W Sachs [mailto:mwsachs@us.ibm.com] > Sent: Friday, January 04, 2002 9:30 AM > To: Ralph Berwanger > Cc: Christopher Ferris; David Fischer; Arvola Chan; ebXML Msg; Ian. C. > Jones (E-mail) > Subject: RE: [ebxml-msg] Messaging Spec v1.092 > > > > This might be a case for including a non-normative explanation of what is > intended. > > 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 > **************************************************************************** **** > ***** > > > > Ralph Berwanger <rberwanger@bTrade.com> on 01/04/2002 09:55:17 AM > > To: Christopher Ferris <chris.ferris@sun.com> > cc: David Fischer <david@drummondgroup.com>, Arvola Chan > <arvola@tibco.com>, ebXML Msg <ebxml-msg@lists.oasis-open.org>, > "Ian. C. Jones (E-mail)" <ian.c.jones@bt.com> > Subject: RE: [ebxml-msg] Messaging Spec v1.092 > > > > Chris, > I agree with the technique. I can even make a convincing > argument for including the capability. I would think that if a message > originator requested a signed receipt and did not elect to sign the > original document that the orignator would have a facility to validate > the signature value returned in the receipt. > I have a significant collection of legacy data and I am having > trouble processing this discussion in light of many previous debates, to > include those with members of the ABA and some elements of the Federal > Government. My issue boils down to, "I am concerned about the > perceptions it may spawn." This may not be sufficient enough reason to > vote against supporting the capability. I can remember early > discussions regarding dis-embodies signatures and the number of people > asking, "who would ever do that?" > > Ralph > > -----Original Message----- > From: Christopher Ferris [mailto:chris.ferris@sun.com] > Sent: Friday, January 04, 2002 8:40 AM > To: Ralph Berwanger > Cc: David Fischer; Arvola Chan; ebXML Msg; Ian. C. Jones (E-mail) > Subject: Re: [ebxml-msg] Messaging Spec v1.092 > > > Ralph, > > Right, but if I'm not mistaken, the receipient sends > a signed receipt before it receives the original signed > digest. The distinction is that while the process involves > signatures in both directions, the implementation details > are such that from the perspective of the MSH, the original > message is *not* signed and the receipt (ack) *is* signed. > > Cheers, > > Chris > > Ralph Berwanger wrote: > > > Chris, your example is sort of correct . It is a case where > signatures > > are sent independent of the document being signed. The exact process > is > > not important, what is important is that the banks are sending a > > signature for the original documents--independent of the original > > documents. This is one of the defined uses of the EDIFACT AUTACK > > message. This business process was driven by the high cost of > > telecommunications services and the business hours of bank officials. > > But you see, there is a signature related to the original message and > > that is the point. The business case does not expect a signed > response > > to a non-signed message. > > > > Ralph Berwanger > > > > -----Original Message----- > > From: Christopher Ferris [mailto:chris.ferris@sun.com] > > Sent: Friday, January 04, 2002 8:21 AM > > To: Ralph Berwanger > > Cc: David Fischer; Arvola Chan; ebXML Msg; Ian. C. Jones (E-mail) > > Subject: Re: [ebxml-msg] Messaging Spec v1.092 > > > > > > Actually, I agree with David. It may seem that it isn't > > secure, but in fact, it can be. I believe that I've heard > > of a banking application that doesn't sign individual > > messages, but *does* calculate a digest for each which is > > stored before the message is sent. The recipient then also > > calculates the digest and sends a signed receipt (equivalent) > > over the calculated digest which the original sender then > > compares with the original digest (as well as validating > > the signature certificates, etc.). At the end of the > > day, the original sender then sends a signed message > > that contains information that indicates whether any > > of the digests mismatched and *then* the recipient can > > process the batch it received knowing that they were > > securely received intact and untampered. > > > > Cheers, > > > > Chris > > > > Ralph Berwanger wrote: > > > > > >>David, > >> > >> I must disagree with you on item 9. It makes NO sense to return a > >> > > > >>signed receipt for a document that did not contain an original > >>signature. I know that the intent is to provide the message > >> > > originator > > > >>with some sense of security; however, it is not really achieved and it > >> > > > >>may in fact provide them a false sense of security. They may assume > >> > > that > > > >>the signed receipt makes a legal statement that it cannot make. This > >> > > is > > > >>not a technical issue, it is a legal and business issue--we will do > >> > > the > > > >>community a disservice if we support signed receipts for unsigned > >>messages.I have been around this argument many times with the same > >>findings. > >> > >> > >> > >>Ralph Berwanger > >> > >> -----Original Message----- > >> From: David Fischer [mailto:david@drummondgroup.com] > >> Sent: Thursday, January 03, 2002 7:48 PM > >> To: Arvola Chan; ebXML Msg; Ian. C. Jones (E-mail) > >> Subject: RE: [ebxml-msg] Messaging Spec v1.092 > >> > >> Comments inline. > >> > >> > >> > >> Ian, > >> > >> We still have a couple of unresolved issues -- most notably the > >> signature problem Sanjay pointed out. There is also the issue > >> > > (item > > > >> 6 below) that SyncReply does not work with Intermediate > >> Acknowledgments. We are supposed to start voting tomorrow. What > >> shall we do? If you would like, I can go ahead and post as > >> > > version > > > >> 1.093? > >> > >> > >> > >> I want to thank everyone for all the help on editing/reviewing the > >> specification. I think this is a much better spec than v1.0. > >> > > That > > > >> said, I will also say I plan to vote *no* on this spec for two > >> reasons: 1) Our charter was to create a v1.1 spec with "fixes and > >> clarifications only" which we have failed to do (if we > >> could name this spec v2.0, as the RegRep team did, then this > >> objection would go away), and 2) Our original charter was to > >> create a set of "orthogonal ebXML specifications" which we have > >> failed to do (we have tightly coupled Messaging with CPPA). I > >> > > would > > > >> like to urge everyone to consider a version number of v2.0 since > >> v1.1 has the connotation of backward compatibility which we > >> certainly have not achieved. Our next version could then be v3.0? > >> > >> > >> > >> Please let me know what you want to do. > >> > >> > >> > >> David. > >> > >> -----Original Message----- > >> From: Arvola Chan [mailto:arvola@tibco.com] > >> Sent: Wednesday, January 02, 2002 2:34 PM > >> To: David Fischer; ebXML Msg > >> Subject: Re: [ebxml-msg] Messaging Spec v1.092 > >> > >> David: > >> > >> > >> > >> Here are some belated editorial comments. I hope they can be > >> fixed without too much trouble: > >> > >> 1. Line 18: Don't we have to wait for a calendar quarter > >> boundary before the spec can be presented to the OASIS > >> membership for consideration as an OASIS specification? > >> > > > >> <df>Fixed -- this means we will submit on April Fools > >> > > Day > > > >> ;-) > >> We still don't have anything under the *This > >> Version* heading</df> > >> 2. Line 311: The reference to [ebREQ] cannot be found among > >> the Non-Normative References (see line 2761). > >> <df>Added Reference</df> > >> 3. LIne 896: The permissible values for > >> > > duplicateElimination > > > >> in the CPA are perMessage, never, and always. Therefore, > >> replace "set to false" with "set to never" on line 897. > >> Note: this is with respect to the 1.1 CPP/A spec. Do we > >> need to add a reference to the forthcoming 1.1 CPP/A > >> > > spec? > > > >> <df>done</df> > >> 4. Line 1384: The schema says that this is a REQUIRED > >> attribute. It must be set to the value > >> "http://schemas.xmlsoap.org/soap/actor/next > >> <http://schemas.xmlsoap.org/soap/actor/next>". It is > >> somewhat different from being declared as a FIXED > >> attribute in the schema. Line 1384 seems to suggest the > >> latter. Excerpts from the SOAP 1.1 spec: "The SOAP actor > >> global attribute can be used to indicate the recipient > >> > > of > > > >> a header element. The value of the SOAP actor attribute > >> > > is > > > >> a URI. The special URI > >> "http://schemas.xmlsoap.org/soap/actor/next" indicates > >> that the header element is intended for the very first > >> SOAP application that processes the message. This is > >> similar to the hop-by-hop scope model represented by the > >> Connection header field in HTTP. Omitting the SOAP actor > >> attribute indicates that the recipient is the ultimate > >> destination of the SOAP message. This attribute MUST > >> appear in the SOAP message instance in order to be > >> effective (see section 3 > >> <http://www.w3.org/TR/SOAP/#_Toc478383492> and 4.2.1 > >> <http://www.w3.org/TR/SOAP/#_Toc478383498>)." > >> <df>Changed "fixed" to "REQUIRED"</df> > >> 5. Line 1389: CPP/A attribute names start with a lower > >> > > case. > > > >> SyncReplyMode should be globally repaced with > >> > > syncReplyMode. > > > >> <df>done</df> > >> 6. Line 1412: I like to point out that a SyncReply element > >> > > is > > > >> not compatible with an AckRequested element that is > >> targeted at the next MSH. > >> <df>No resolution yet.</df> > >> 7. Line 1491: I think an errorCode of Inconsistent should > >> > > be > > > >> accompanied by a severity of Error rather than warning. > >> Didn't we decide that inconsistency between the CPA and > >> the message header must always result in an error being > >> returned? > >> <df>This might not be an inconsistency with the CPA > >> (perMessage). If we say this must be an Error then we > >> must also say the To Party MSH MUST NOT deliver to the > >> Application. IMO This needs to be a Warning.</df> > >> 8. 1502: The statement "An Error Message MUST NOT contain > >> > > an > > > >> AckRequested element" is not correct and should be > >> > > struck > > > >> out. Please see > >> > >> > > http://lists.oasis-open.org/archives/ebxml-msg/200111/msg00231.html > > (Resolution > > > >> of issues in the issues database), IssueId 73, and/or > >> > >> > > http://lists.oasis-open.org/archives/ebxml-msg/200111/doc00004.doc, > > > >> Issue 73. > >> <df>We have gone back and forth on this several times. > >> > > I > > > >> think the latest was to change to *no Ack on Error*. If > >> we go back to *no Error on Ack* then I need to go back > >> through the spec and make several changes. See > >> *[ebxml-msg] Ack on Error, or Error on Ack* thread > >> starting 12/10/01.</df> > >> 9. Line 1557: I think it is inconsistent to ask for a > >> > > signed > > > >> Acknowledgment if the original message is not signed. > >> <df>Why? I agree it sounds strange but I can't think of > >> any reason it would be inconsistent. Someone might want > >> NRR but there is no reason to sign.</df> > >> 10. Line 1579: It will be useful to point out that > >> > > parameters > > > >> that are not found in the message header are to be > >> obtained from the CPA. > >> <df>??? It already says this?</df> > >> 11. Line 1584: Replace "value of duplicateElimination in the > >> CPA is false" with "value of duplicateElimination in the > >> CPA is never". > >> <df>done</df> > >> 12. Line 1591: I think it may be problematical for the > >> recipient to do duplicate elimination when no > >> DuplicateElimination element is present. What happens if > >> SyncReply is present and AckRequested is not present. If > >> the incoming message is not passed on to the > >> > > application, > > > >> should any reply be returned to the sender? > >> <df>Resolved between Arvola and Doug</df> > >> 13. Line 1602: It will be useful to point out that the > >> > > Retries > > > >> parameter comes from the CPA. > >> <df>done</df> > >> 14. Line 1605: It will be useful to point out that the > >> RetryInterval parameter comes from the CPA. > >> <df> done </df> > >> 15. Line 1616: It will be useful to point out that the > >> PersistDuration parameter comes from the CPA. > >> <df> done </df> > >> 16. Line 1625: As mentioned earlier, SyncReplyMode should be > >> spelt as syncReplyMode. Also, I just noticed the > >> > > following > > > >> statement in the 1.0 CPP/A spec. "If the delivery > >> > > channel > > > >> identifies a transport protocol that has no synchronous > >> capabilities (such as SMTP) and the Characteristics > >> element has a syncReplyMode attribute with a value other > >> than "none", a response SHALL contain the same content > >> > > as > > > >> if the transport protocol did support synchronous > >> responses." which contradicts the statement on line > >> > > 1625: > > > >> "The SyncReplyMode parameter from the CPA is used only > >> > > if > > > >> the data communications protocol is synchronous (e.g. > >> > > HTTP)." > > > >> <df> Resolved </df> > >> 17. Line 1646: The sentence is missing a closing period. > >> <df> done </df> > >> 18. Line 1678: This seems to contradict the statement on > >> > > line > > > >> 1589. > >> <df> deleted </df> > >> 19. Line 1684: There is an invalid reference to section 0. > >> <df> deleted </df> > >> 20. Line 1733 and line 1738: These two bullet points assume > >> that syncReplyMode in the CPA is not used with an > >> asynchronous communication channel. This is in conflict > >> with the 1.0 CPP/A spec statement quoted in item 15 > >> > > above. > > > >> I think this is a minor technical issue that may require > >> some discussion. > >> <df> Resolved </df> > >> 21. Line 1772: Since one MSH is not allowed to place more > >> > > than > > > >> one AckRequested element in the SOAP Header (according > >> > > to > > > >> line 1469), this matrix represents what an intermediary > >> MSH or the To Party MSH may receive, not what the From > >> Party MSH may send. > >> <df> Does this mean 1468/9 is wrong? It already says > >> *SHOULD* so maybe no change is needed.</df> > >> 22. Line 2098: I think the statement "The Receiving MSH MUST > >> NOT send an Acknowledgment Message until the message has > >> been delivered to the Next MSH" is not correct. This > >> > > does > > > >> not correspond to store and forward behavior (see line > >> 2043). The Receiving MSH cannot know for sure that the > >> message has been delivered to the Next MSH until it > >> receives an Acknowledgment from the latter. The > >> > > prescribed > > > >> behavior defeats the purpose of intermediate > >> > > Acknowledgments. > > > >> <df> What would be more correct? Should it say *The > >> Receiving MSH MUST NOT send an Acknowledgment Message > >> until the message has been persisted?* Actually, I > >> > > don't > > > >> see a problem as it is. What should I do? </df> > >> 23. Line 2619: This comment seems unnecessary. Would it > >> constitute an unrecognized MIME header? > >> <df> Yes, this is unnecessary. No this is not illegal. > >> Everything between the first blank line and the first > >> boundary is ignored. It is common for vendors to put > >> advertising info in this space -- identify the product > >> > > or > > > >> vendor software producing this message. </df> > >> > >> Regards, > >> > >> -Arvola > >> > >> > >> > >> ----- Original Message ----- > >> > >> From: "David Fischer" <david@drummondgroup.com > >> <mailto:david@drummondgroup.com>> > >> > >> To: "ebXML Msg" <ebxml-msg@lists.oasis-open.org > >> <mailto:ebxml-msg@lists.oasis-open.org>> > >> > >> Sent: Thursday, December 20, 2001 7:25 PM > >> > >> Subject: [ebxml-msg] Messaging Spec v1.092 > >> > >> > >> > This is the spec as it stands now. I think everyone's > >> comments are included > >> > (I'm mad at Doug for sending pages and pages of very good > >> comments AT THE LAST > >> > MINUTE ;-) > >> > > >> > Please get any last minute comments to me quickly. Please > >> > > no > > > >> large changes at > >> > this point. > >> > > >> > Ian, I still need to resolve the copyright issue. Also, we > >> need to decide on > >> > the problem Sanjay described (I added the change as hidden > >> text if anyone wants > >> > to look at it). > >> > > >> > If anyone needs this in PDF, please let me know. > >> > > >> > Regards, > >> > > >> > David Fischer > >> > Drummond Group > >> > ebXML-MS Editor. > >> > > >> > >> > > > > > > > > ---------------------------------------------------------------- > > To subscribe or unsubscribe from this elist use the subscription > > manager: <http://lists.oasis-open.org/ob/adm.pl> > > > > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> > > > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> > > > ---------------------------------------------------------------- > 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