Re: Revised core section 4.3.3.1

Ok,

http://www.w3.org/Signature/Drafts/WD-xmldsig-core-200003plc/#sec-Transforms

At 17:17 2000-05-01 -0400, Donald Eastlake 3rd wrote:
 >Here is the revised section 4.3.3.1 to eliminate the MimeType and
 >Charset attributes and provide for them as parameters.  It claims
 >that none of the Transforms specified in the doc need them but 
 >is this true form canonicalization?
 >
 ><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
 ><html>
 >
 ><body>
 ><h4>4.3.3.1 The <a name="sec-Transforms"><code>Transforms</code></a>
Element </h4>
 >
 ><p>The optional <code>Transforms</code> element contains an ordered
 >list of <code>Transform</code> elements; these describe how the
 >signer obtained the data object that was digested. The output of each
 ><code>Transform</code> (octets) serves as input to the next
 ><code>Transform</code>.  The input to the first <code>Transform</code>
 >is the source data. The output from the last <code>Transform</code> is
 >the input for the <code>DigestMethod</code> algorithm. When transforms
 >are applied the signer is not signing the native (original) document
 >but the resulting (transformed) document (See section 8.2: <a
 >href="#sec-Seen">Only What is &quot;Seen&quot; Should be Signed</a>.)
 ></p>
 >
 ><p>Each <code>Transform</code> consists of an <code>Algorithm</code>
 >attribute and content parameters, if any, appropriate for the given
 >algorithm. The <code>Algorithm</code> attribute value specifies the
 >name of the algorithm to be performed, and the <code>Transform</code>
 >content provides additional data to govern the algorithm's processing
 >of the input resource (see section 6.1: <a href="#sec-AlgID">Algorithm
 >Identifiers and Implementation Requirements</a>).</p>
 >
 ><p>Some <code>Transform</code> may require explicit
 ><code>MimeType</code>, <code>Charset</code> (IANA
 >registered character set), or other such information
 >concerning the data they are receiving from an earlier
<code>Transform</code>
 >or the source data, although no 
 ><code>Transform</code> algorithm specified in this document needs 
 >such information.  Such data characteristics are provided as
 >parameters to the <code>Transform</code> algorithm and should be
 >described in the specification for the algorithm. </p>
 >
 ><pre class="xml-dtd">   Schema Definition:
 >
 >   &lt;element name='Transforms' &gt; 
 >     &lt;complexType content='elementOnly'&gt; 
 >       &lt;element ref='ds:Transform' minOccurs='1' maxOccurs='*'/&gt;  
 >     &lt;/complexType&gt;
 >   &lt;/element&gt; 
 >
 >   &lt;element name='Transform'&gt; 
 >     &lt;complexType content='mixed'&gt;
 >       &lt;any minOccurs='0' maxOccurs='*'/&gt;
 >       &lt;attribute name='Algorithm' type='string' minOccurs='1'
maxOccurs='1'/&gt; 
 >     &lt;/complexType&gt;
 >   &lt;/element&gt; 
 ></pre>
 >
 ><pre class="xml-dtd">   DTD:
 >
 >   &lt;!ELEMENT Transforms (Transform+)&gt;
 >
 >   &lt;!ELEMENT Transform (#PCDATA)&gt;
 >   &lt;!ATTLIST Transform 
 >             Algorithm    CDATA     #REQUIRED &gt;
 ></pre>
 >
 ><p>Examples of transforms include but are not limited to base64
 >decoding [<a href="#ref-MIME">MIME</a>], canonicalization [<a
 >href="#ref-XML-c14n">XML-c14n</a>], XPath filtering [<a
 >href="#ref-XPath">XPath</a>], and XSLT [<a
 >href="#ref-XSLT">XSLT</a>]. The generic definition of the
 ><code>Transform</code> element also allows application-specific
 >transform algorithms. For example, the transform could be a
 >decompression routine given by a Java class appearing as a base64
 >encoded parameter to a Java <code>Transform</code> algorithm. However,
 >applications should refrain from using application-specific transforms
 >if they wish their signatures to be verifiable outside of their
 >application domain.  Section 6.6: <a HREF="#sec-Transforms">Transform
 >Algorithms</a> defines the list of standard transformations. </p>
 >
 ></body>
 ></html>
 >
 >==================================================================
 > Donald Eastlake 3rd  +1 978-562-2827(h)  dee3@torque.pothole.com
 > 140 Forest Avenue     +1 508-261-5434(w)  lde008@dma.isg.mot.com
 > Hudson, MA 01749 USA
 >

_________________________________________________________
Joseph Reagle Jr.   
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/

Received on Tuesday, 2 May 2000 15:39:22 UTC