Hans,

see attached e-mail that contains Raul's answer to an
e-mail on the xml-sec list.

AFAIK Raul did some real improvements in the xml-sec library
concernig speed, memory footprint, etc. 

In the follow-up of this e-mail I asked Raul how to remove 
cricumventBug2650 from our EnvelopeIdResolver. After some 
experiments and digging into the c14n spec I finally got it.

Seems that it works as expected.

Regards,
Werner

> -----Ursprüngliche Nachricht-----
> Von: Granqvist, Hans [mailto:[EMAIL PROTECTED] 
> Gesendet: Montag, 26. September 2005 17:29
> An: Werner Dittmann; [email protected]
> Betreff: RE: STR Transform, use of XPath, xml-sec library etc.
> 
> 
> Werner: I can't find the xml-sec thread that discussed this. Do you
> have a direct ref?
> 
> > ...
> > Using xpath transformation is always one order the magnitude slower.
> 
> Slower than using fragment refs?  This statement seems unfair.  What 
> Xpath engine could possibly be this slow??
> 
> > ...
> > And, according to Raul's statement: when modifying code, 
> > adding new features etc we shall be carefull not to use XPath :-)
> 
> That is only true because some Xpaths look complex. Simple, direct,
> Xpaths are quite useful in that they are immediately axiomatic.
> 
> And let's not forget the whole wsu:Id/Id/ID crapola! :o 
> 
> See 8.2 in [1] for discussion on the occasional need to use Xpath.
> 
> Thanks
> Hans
> 
> [1] http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html
> 
> > 
> > Regards,
> > Werner
> > 
> > 
> ---------------------------------------------------------------------
> > 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]
> 
> 
--- Begin Message ---
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 <[EMAIL PROTECTED]> 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


--- End Message ---
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to