Hi Yinghui, well, XML is word/text processing after all, isn't it? :-))
IMHO one should treat XML similar to binary data. Unfortunatly applications often set up parsers (XML to DOM) or serializers (DOM to XML) in a way to produce "human readable" output even if this is not necessary or even problematic. My idea would be: configure the parser/serializer at the intermediate node to handle "XML" has a sort of binary data. Regards, Werner > -----Ursprüngliche Nachricht----- > Von: yinghui chen [mailto:[EMAIL PROTECTED] > Gesendet: Freitag, 11. November 2005 09:26 > An: Dittmann, Werner; [email protected] > Betreff: RE: AW: AW: signature verification fail when > modifying soap body by intermediate > > Hello, Werner, > So it seems like if I inserts the new element directly into > XML string > without using XML parser, I should be able to solve the > problem. But it is > kind of tedious. Do you have any better idea? Isn't it quite > common for a > intermediate to insert new element into SOAP body? It seems not very > efficient for a intermediate to always treat a XML document > just XML String. > > Best Regards, > Yinghui > > >From: "Dittmann, Werner" <[EMAIL PROTECTED]> > >To: "yinghui chen" <[EMAIL PROTECTED]>, <[email protected]> > >Subject: AW: AW: signature verification fail when modifying > soap body by > >intermediate > >Date: Fri, 11 Nov 2005 09:09:23 +0100 > > > >Hi Yinghui, > > > >it is a very common misunderstanding that canonicalization > >removes what you call "insignificant change". This is not > >true. C14n canonicalizes the namespace ordering, > >which namespaces to use, etc. Also the parser usually performs > >some adjustments inside the tags. But c14n does not modify/remove > >data that appears outside the tags, e.g. newlines that were added > >to do "pretty printing" or something else. > > > >Regards, > >Werner > > > > > -----Ursprüngliche Nachricht----- > > > Von: yinghui chen [mailto:[EMAIL PROTECTED] > > > Gesendet: Freitag, 11. November 2005 08:53 > > > An: Dittmann, Werner; [email protected] > > > Betreff: RE: AW: signature verification fail when modifying > > > soap body by intermediate > > > > > > Hello, Werner, > > > Many thanks for the response. You are right that > > > constructing a new DOM > > > tree might modify element in some way. But before signature > > > verification, > > > the XML should go through the canonicalization process, which > > > should make > > > sure any insignificant change, for example, line feed, extra > > > blank space > > > etc, should not effect the signature verification. So do you > > > think it might > > > be a kind of bug within canonicalization code? > > > > > > Best Regards, > > > Yinghui > > > > > > > > > >From: "Dittmann, Werner" <[EMAIL PROTECTED]> > > > >To: "yinghui chen" <[EMAIL PROTECTED]>, > <[email protected]> > > > >Subject: AW: signature verification fail when modifying > soap body by > > > >intermediate Date: Fri, 11 Nov 2005 08:22:32 +0100 > > > > > > > >Yinghui, > > > > > > > >that failure may have several reasons. Fist of all, > > > >you are right that modifiying/addin an element that was > > > >not part of the Signature should not cause the verification > > > >to fail. > > > > > > > >However, my assumption is that during the modification of the > > > >body ny adding another element also the original element (A) > > > >is modifiy somehow. To add the second element (B) someone > > > >usually needs to parse the body, building a DOM tree, insert > > > >the new element and serialize the DOM into a new body. > > > > > > > >If during this parsing/inserting/serialization process > the element > > > >A is modifiyied in some way the verification fails. Modification > > > >in this case mean e.g. adding a newline character, a blank, a tab > > > >or something else. This very often occurs during the > above mentioned > > > >steps. After Singing an element this element _must not_ > be modified > > > >in the way described above. You may check the whole stuff if you > > > >really look at the request using e.g. TCPMON before the request > > > >enters procesing of company B and after processing. > > > > > > > >Regards, > > > >Werner > > > > > > > > > -----Ursprüngliche Nachricht----- > > > > > Von: yinghui chen [mailto:[EMAIL PROTECTED] > > > > > Gesendet: Donnerstag, 10. November 2005 22:32 > > > > > An: [email protected] > > > > > Betreff: signature verification fail when modifying soap body > > > > > by intermediate > > > > > > > > > > Dear All, > > > > > I am currently applying the wss4j for a small project. But > > > > > we are having a > > > > > problem of signature verification failure. Here is the > > > description. > > > > > For example, company A construct a SOAP message, and sign > > > > > element A within > > > > > the SOAP body. And then company A send the SOAP to company B. > > > > > Company B > > > > > insert an element B into the SOAP body. The element B is > > > a sibling of > > > > > element A. And then Company B forward the SOAP to Company C. > > > > > The Company C > > > > > verifies the signature, but it fails. I have tried the case > > > > > if Company B > > > > > does not insert element B, the signature verification > is success. > > > > > The thing that I do not understand is that company A sign > > > > > only element A, > > > > > why insersion of element B break the signature. > > > > > I attached the source code together with the email. > > > > > > > > > > I am looking forward to your help, > > > > > Yinghui > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > >--------------------------------------------------------------------- > > > >To unsubscribe, e-mail: [EMAIL PROTECTED] > > > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
