RE: New Attachments Issues

 

> -----Original Message-----
> From: xml-dist-app-request@w3.org 
> [mailto:xml-dist-app-request@w3.org] On Behalf Of Marc Hadley
> Sent: 11 June 2003 15:30
> To: Jacek Kopecky
> Cc: XMLP Dist App
> Subject: Re: New Attachments Issues
> 
> 
> On Tuesday, Jun 10, 2003, at 10:56 US/Eastern, Jacek Kopecky wrote:
> 
> > I don't think we ever wanted to consider security 
> mechanisms visible 
> > to the application that would be aware of any optimizations not 
> > visible to the application, like the optimization of binary 
> data in SOAP messages.
> > I thought the expectation was that dig-sig or encryption 
> would work on 
> > canonical base64 representation of the data. There can 
> still be some 
> > optimizations in the implementations, e.g. only do the 
> base64 encoding 
> > on the fly for signature computation, never store the actual full
> > base64
> > version of the data. Base64 encoding is cheap and if the signature 
> > code can consume a stream, the cost of base64 encoding will 
> be lost in 
> > the cost of computing the signature, I believe (and 
> somebody else has 
> > mentioned this before me, too).
> >
> I'd like to see some performance data on this, do you have a 
> pointer to any ? In order to make an informed choice I think 
> it behooves us to consider real data rather than make any 
> such assumptions.
> 
> Thanks,
> Marc.
> 

I would observ that signature computation seems to be directly
proportional to the size of the date being signed ( note that this does
NOT include the initialization of the signature computation with keys
etc. ). Therefore, it would be reasonable to assume that computing the
sig over base64 would take exactly a third longer than computing the sig
over the binary.

I hope to do some more tests that include the 'set-up cost' in the
calculation, although once the data passes a give size, I'm sure the
set-up cost becomes minimal as a proportion of overall time.

Gudge

Received on Wednesday, 11 June 2003 13:40:00 UTC