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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

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


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.
>          > 
> 




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


Powered by eList eXpress LLC