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

1. I don't know of a specific uses case but if the group believes we need that level of granularity we could look at what is the best bit padding mechanism.

2. I would think byte/bit ranges signatures are susceptible to the same types of attacks that you can get by using XPath filtering.

3. You couldn't sign a specific bit range, see #1.

4. I don't know if there is a issue with the concatenation of byte/bit ranges because if the definition of the byte ranges is also covered by the signature.

Cheers
Chris.


-----Original Message-----
From: Frederick Hirsch [mailto:frederick.hirsch@nokia.com]
Sent: Monday, November 10, 2008 3:27 PM
To: Chris Solc
Cc: Frederick Hirsch; XMLSec WG Public List
Subject: 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 Tuesday, 11 November 2008 14:02:19 UTC