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: circumventBug2650 - Memory footprint
Date Fri, 23 Sep 2005 11:43:07 GMT
Raul,

after digging a bit more into the problem I see the several
differences. 

The first run was done with calling circumventBug2650(doc), creating
an own node set and using XMLSignatureInput(resultSet) as return from
then EnvelopeIdResolver.

The second run does not call circumventBug2650(doc) and uses
XMLSignatureInput(element) as return from EnvelopeIdResolver.

The Transform (STRTransform) method was not modified.

The debugging info when invoking the Transform function:
First run (circumvent enabled, node set):
- Beginning STRTransform...XMLSignatureInput/NodeSet/19 nodes/null

Second run (circumvent disabled, element):
- Beginning STRTransform...XMLSignatureInput/Element/[wsse:SecurityTokenReference: null] exclude
null comments:false/null

As you can see the input to the transforms are different. 

Depending on the referenced security token the STRTransform either
creates a new element that contains the token or it uses the token
inside of the document. Depending on that there are different results
also.

Another issue: handling of default namespace. According to the WSS
spec the Apex nodes must contain an empty default namespace if no other
default namespace is defined. This can be obtained only using some
hacks. 

However, if I use the way without the cirumvent2650 method / nodeset
then I cannot produce results that are required for the STRTransform.

Regards,
Werner

> -----Urspr√ľngliche Nachricht-----
> Von: Raul Benito [mailto:raul.benito.garcia@gmail.com] 
> Gesendet: Donnerstag, 22. September 2005 21:28
> An: security-dev@xml.apache.org
> Betreff: Re: circumventBug2650 - Memory footprint
> 
> 
> You are right Sean.
> This is always the best way to handle references.
> 
> Anyway I think that we need a FAQ or little article that summaries the
> XML signature best practises.
>  I have tried to do this in the slides that I send. But I don't think
> I manage to do a good job.
> But If anyone is interested in written something about it. I promise
> to support her/him whatever I can.
> 
> Regards,
> 
> Raul
> 
> On 9/22/05, Sean Mullan <Sean.Mullan@sun.com> wrote:
> > What version of XMLSec are you using?
> >
> > Also, don't return an XPath node-set of all the nodes of 
> the element's
> > subtree. By doing this, you will not take advantage of the 
> optimizations
> > in the XMLSec library when canonicalizing subtrees and it 
> could also be
> > the reason you need to invoke circumventBug2650 (Raul will 
> probably know
> > for sure). Instead return an XMLSignatureInput(element) and let the
> > XMLSec library handle the rest.
> >
> > --Sean
> >
> > Werner Dittmann wrote:
> > > Raul,
> > >
> > > in WSS4J we do Signatures. During the Id resolver we call 
> the circumvent
> > > method. AFAIK we do not use XPath to select the nodes to 
> sign, just id
> > > references. After locating the element to sign the 
> resolver constructs
> > > a node set of all nodes to sign. This node set of course includes
> > > all nodes (elements, attributes, text, ...).
> > >
> > > However, when I disable the call of the circumvent method I
> > > get probelms in signature verification. Thus IMHO it is 
> not so easy just
> > > to switch off the circumvent method.
> > > Thus if we don't use the circumvent method: is it 
> possible that we do
> > > not get all required namespace attributes when build the node set?
> > >
> > > Regards,
> > > Werner
> > >
> > > Raul Benito wrote:
> > >
> > >>Don't use any xpath transformation. Select what you want 
> to sign with:
> > >>
> > >> <Reference URI="#whatToSign">..</Reference>
> > >><NodeToBeSigned id="whatToSign">..</NodeToBeSigned>
> > >>
> > >>In this way , the circumventBug2650 is not called(and 
> other several
> > >>optimizations hit). And you can sign bigger documents.
> > >>
> > >>Using xpath transformation is always one order the 
> magnitude slower.
> > >>
> > >>You can see some speed considerations form page 12, in 
> this presentation:
> > >>http://r-bg.com/images/SecuringXMLDocuments.pdf
> > >>
> > >>Regards,
> > >>
> > >>Raul
> > >>
> > >>On 9/21/05, John Lanier <xmlsecure@yahoo.com> wrote:
> > >>
> > >>
> > >>>Hi,
> > >>>
> > >>>The circumventBug2650 function in XMLUtils takes up a
> > >>>significant amount of memory in adding Attributes to
> > >>>each node. Is there any effort underway to rewrite
> > >>>this in a more memory-friendly way?
> > >>>
> > >>>I am unable to sign XML documents larger than about
> > >>>10MB using the current (1.2.x) code base. (Pentium
> > >>>III, 500MB Java heap size).
> > >>>
> > >>>Any pointers from anybody who worked around this bug
> > >>>or managed to sign larger XML docs?
> > >>>
> > >>>Thanks
> > >>>~john
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>__________________________________
> > >>>Yahoo! Mail - PC Magazine Editors' Choice 2005
> > >>>http://mail.yahoo.com
> > >>>
> > >>
> > >>
> > >>
> > >>--
> > >>http://r-bg.com
> > >>
> > >
> > >
> >
> >
> 
> 
> --
> http://r-bg.com
> 

Mime
View raw message