Re: ACTION-85 - Update the proposal on a ByteRange Transform

 From the F2F I noted the following questions regarding ByteRange  
transform:

1. why bytes and not bits. Here it is answered based on the transform  
mechanism in XML Signature. Is there a use case for bit ranges?  
Related, is there a need for defining padding operation in a proposed  
transform?

2. Which attacks are possible for byte ranges, and which  
countermeasures are appropriate?

3. What are the limitations of this proposal?

4. Is there any issue with concatenation of byte ranges? (whoever  
raised this might want to add detail).

regards, Frederick

Frederick Hirsch
Nokia



On Nov 10, 2008, at 3:00 PM, ext Chris Solc wrote:

>
> Use Case:
> A digital image file contains the raw image data and optional  
> metadata. This metadata contains information like the date the photo  
> was taken, exposure information, search info, general description,  
> etc.  Now a photographer wants to use an XML signature to digital  
> sign their photo to ensure it isn't modified by someone, but still  
> wants allows other users to add new meta-data to their photo.  This  
> can only be done if the photographer only signs the raw image data  
> and excludes the metadata.
>
> Requirement:
> XML signature 1.0 specification allows authors of XML signatures to  
> sign a subset of an XML document, but doesn't define any grammar  
> that allows a subset of a non XML resource to be signed.  The  
> requirement for the next version of the XML signature specification  
> is to define some grammar that allows a subset of a non XML resource  
> to be signed.
>
> Proposal:
> Add a new ByteRange transform that produces as output, a subset of  
> the input octet stream. Note that byte ranges are used instead of  
> bit ranges because XML Signatures specification defines transforms  
> for octet streams and not bit streams.  The Byte-Range transform  
> contains a collection of byte ranges defined by a starting byte  
> offset and an optional length value. When the ranges are  
> concatenated together it describe the exact set of bytes from the  
> input octet stream to be used in the digest calculation of the  
> signatures.
>
> Example:
> <Signature xmlns="http://undefined.namespace">
>   <SignedInfo>
>      ...
>      <Reference URI="./image.jpeg">
>         <Transforms>
>           <Transform Algorithm="undefined.namespace#ByteRange">
>             <ByteRange>
>               <Range offset="0" length="20"/> <!-- first 20 bytes of  
> the image -->
>               <!-- bytes 21 to 219 are excluded -->
>               <Range offset="220" length="50"/>  <!-- bytes 220 to  
> 270 -->
>               <!-- bytes 271 to 319 are excluded -->
>               <Range offset="320" />  <!-- bytes 320 to end of file  
> -->
>             </ByteRange>
>           </Transform>
>         </Transforms>
>         <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1 
> "/>
>         <DigestValue>...</DigestValue>
>      </Reference>
>  </SignedInfo>
>  <SignatureValue>...</SignatureValue>
> </Signature>
>
>

Received on Monday, 10 November 2008 20:28:18 UTC