Re: New attachments issues

Martin and I exchanged some email off-line, just to make sure we each 
understood each other. :)  Here's my Noah-like attempt to get it all 
down in one note.

A single XML DSIG can cover multiple data sources within a single 
signature, by including multiple dsig:Reference elements.  The reference 
has a digest (hash), a URI to point to the data, and an optional set of 
transformations.  Transformations are applied in order, so one can say 
"run this stylesheets, and then canonicalize the results" for example.
There are about 3 or 4 XML canonicalization algorithms for XML DSIG 
(c14n, exc-c14n, UDDI's schema-aware c14n, and soap message 
normalization are the main ones that come to mind). All of them assume 
that they are working on valid XML 1.0 data; this means that arbitrary 
binary data isn't legal.

The issue is how do you sign
    <m:MyElement someattr='blah' >
       <xbinc:Include href='someuritoanattachment' />
    </m:MyElement>
where the data is binary.  In the Inofset it's base64.  There are a 
couple of approaches:

1.   Define a new C14N mechanism; I recommend against this.  WS-Security 
seems like the way the market is going to do XML DSIG, and that strongly 
recommends exc-c14n.  Getting all xml dsig vendors to buy into this, and 
its necessary integration with their customer's infoset, might be very hard.

2.   Don't try to sign binary data; this is in accord with current c14n 
mechanisms which will want a base64 bytestream anyway, as described 
above in the no-binary sentences.

3.  Use two dsig:References: one for the element and its attributes and 
another for the binary content.

4.  Sign just the content, treating it as binary.

For what it's worth, my preference is #2.  We crypto guys are used to 
dealing with base64 all the time, anyway. :)

In another posting, Gudge asked by signing times.  In most cases (i.e., 
assuming no tricky XSLT transforms involved), the cost of signing is 
ka+b, where a is the length of the data, and b is fixed based on the 
number of bits in the key.

Hope this helps.
	/r$

-- 
Rich Salz, Chief Security Architect
DataPower Technology                           http://www.datapower.com
XS40 XML Security Gateway   http://www.datapower.com/products/xs40.html
XML Security Overview  http://www.datapower.com/xmldev/xmlsecurity.html

Received on Wednesday, 11 June 2003 15:34:19 UTC