santuario-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dittmann, Werner" <werner.dittm...@siemens.com>
Subject AW: [Java] C14N of DocumentFragment
Date Wed, 27 Jul 2005 06:19:27 GMT
Raul, Vishal,

in the WSS4J project we use the xml-sec java lib and
we discovered a similar problem about more than a year
ago with the same setup: Verifying a part of a document
after decryption. We solved that problem somehow :-). As
far as I can remember the fix was done in the encryption and
decryption methods of xml-sec - it surely was some sort of
workaround.
We also had some discussions on the mailing list regading
this. At that time I did some fixes in the encryption
and decryption part because we needed a stable version
there.

Probably we need to crosscheck and maybe we can remove
the workaround in the encryption/decryption methods (if
it still exists).

Regards,
Werner

> -----Urspr√ľngliche Nachricht-----
> Von: Raul Benito [mailto:raul.benito.garcia@gmail.com] 
> Gesendet: Dienstag, 26. Juli 2005 23:50
> An: security-dev@xml.apache.org
> Betreff: Re: [Java] C14N of DocumentFragment
> 
> 
> It sounds good. I will try to writte a test that stress this problem
> with your suggestions,
> 
> Do you mind to fill a bugreport? or if you want i can do for you?
> 
> Regards,
> 
> On 7/26/05, Vishal Mahajan <vmahajan@amberpoint.com> wrote:
> > Raul Benito wrote:
> > 
> > >If you think so... Then I will also do it in CVS head.
> > >Anyway can you send a test case?
> > >
> > I can write one but I do know of a scenario when it can be seen.
> > If you try to verify a signature after a decryption 
> operation has been
> > performed on the same document, this problem can be 
> observed. This is
> > because, the decryption (Java version) step creates a 
> document fragment
> > out of the decrypted content and places it under the 
> appropriate parent
> > node. Next if you try to verify a signature on that parent 
> node, you'll
> > have to handle the c14n of its document fragment child.
> > 
> > Thanks,
> > 
> > Vishal
> > 
> > > so i can test it and include to the
> > >testsuite for the future.
> > >
> > >Regards
> > >
> > >Raul
> > >
> > >On 7/24/05, Vishal Mahajan <vmahajan@amberpoint.com> wrote:
> > >
> > >
> > >>I observed a possible bug in the CanonicalizerBase class. 
> If the node
> > >>passed to method canonicalizeSubTree(Node, 
> NameSpaceSymbTable) is of
> > >>type DocumentFragment, currently an exception is thrown. 
> I think the
> > >>behavior in such a case should be same as that for a 
> Document type node.
> > >>Just wanted to confirm this. I have also pasted the patch 
> below (Note
> > >>that the patch is against the 1.2.1 version of the code).
> > >>
> > >>Vishal
> > >>
> > >>--------------------------------------------------------
> > >>--- CanonicalizerBase.java.orig Mon Feb 28 21:55:58 2005
> > >>+++ CanonicalizerBase.java      Sun Jul 24 23:15:33 2005
> > >>@@ -165,10 +165,10 @@
> > >>
> > >>       case Node.ENTITY_NODE :
> > >>       case Node.NOTATION_NODE :
> > >>-      case Node.DOCUMENT_FRAGMENT_NODE :
> > >>       case Node.ATTRIBUTE_NODE :
> > >>          // illegal node type during traversal
> > >>          throw new CanonicalizationException("empty");
> > >>+      case Node.DOCUMENT_FRAGMENT_NODE :
> > >>       case Node.DOCUMENT_NODE :
> > >>          for (Node currentChild = currentNode.getFirstChild();
> > >>                  currentChild != null;
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > >
> > 
> > 
> > 
> 
> 
> -- 
> http://r-bg.com
> 

Mime
View raw message