[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-msg] Messaging Spec v1.092
Regardless of whether the original message is signed or not, the reference element of a signed acknowledgment SHOULD ALWAYS be computed, not copied from the original message, by the receiving party. I don't think that we can say MUST in this situation but it is a REALLY BAD IDEA to simply copy the received digest in this case. Cheers, Chris Arvola Chan wrote: > 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