- From: Donald E. Eastlake 3rd <dee3@torque.pothole.com>
- Date: Tue, 12 Oct 1999 08:16:43 -0400
- To: <jboyer@csr.csc.UVic.CA>, "DSig Group" <w3c-ietf-xmldsig@w3.org>
Hi,
From: "John Boyer" <jboyer@uwi.com>
To: "Joseph M. Reagle Jr." <reagle@w3.org>,
"Donald E. Eastlake 3rd" <dee3@torque.pothole.com>,
"David. Solo@Citicorp. Com" <david.solo@citicorp.com>,
<jboyer@csr.csc.UVic.CA>
Cc: "DSig Group" <w3c-ietf-xmldsig@w3.org>
Date: Sat, 9 Oct 1999 23:39:13 -0700
Message-ID: <NDBBLAOMJKOFPMBCHJOIOEJBCBAA.jboyer@uwi.com>
>In accordance with the request of the most recent teleconference, I've put
>together a draft of Section 7.6 Transformation Algorithms. Although most of
>the text of 7.6 would not be affected by this, I also propose new sections
>4.3.1 Location and 4.3.3 Transformations in order to achieve consistency.
>
>I am on vacation next week to work, but I am at home working on my
>dissertation so I will be able to check email regularly, except that you
>will have to send it to jboyer@csr.uvic.ca. I would like to hear back from
>the chairs as soon as possible regarding the work below. This includes
>contact on Monday (which is a holiday in Canada).
>
>Thanks,
>John Boyer
>Software Development Manager
>UWI.Com -- The Internet Forms Company
>
>Contents:
>Proposed new section 4.3.1
>Proposed new section 4.3.3
>Changes to algorithm table in Section 7
>First draft of section 7.6
>
>Proposed new section 4.3.1
>==========================
>
><h3>4.3.1 <code>Location</code> </h3>
>
><p>The <code>Location</code> identifies the Object using a URI. As the
>terms are
>defined in <a href="#URI">RFC2396 [URI]</a>, some URIs are used in
>conjunction with a
>fragment identifier by use of a separating hash (#), but the URI
>does not include the fragment identifier. <code>Location</code> only
>permits a
>URI, and fragment identification is covered under
><a href="#Transformations">Transformations</a>.</p>
As per my other postings, I believe that we should allow a fragement
here by itself ("#IDABC") because that is really all that you can
reasonably require support for in the Location elements at the top
level. In that case, they are referring to IDs in the same piece of
XML where the Signature occurs and at least you can recognize them on
Object, KeyInfo, and other elements we specify. Many applications
will also be able to recognize them on other element due to being
built in or, in some cases, having access to a DTD.
While I don't feel that strongly about allowing frament notation on
URIs, it seems a bit inconsistent to allow a naked fragment but not
one on a URI.
><p class="xml-dtd"><!ELEMENT Location (#PCDATA)><br>
><br>
><!-- The content conforms to the productions specified by [URI] -->
></p>
>
><p>If the URI indicates an XML document, the document is assumed to
>be unparsed prior to the application of <code>Transformations</code>. If
>there
>are no <code>Transformations</code>, then the indicated resource is passed
>to
>the digest algorithm with only the default canonicalization applied.</p>
>
><p>This element may be omitted if the location is implicit in the
>application. This is useful for closed model signature
>applications that know the referent based on processing context.
>However, these applications abuse the notion of the open Web model
>and their signatures will be of no utility outside of the
>application domain.</p>
>
>Proposed new section 4.3.3
>==========================
>
><h3>4.3.3 <code name="Transformations">Transformations</code> </h3>
>
><p><code>Transformations</code> is an optional element that contains one or
>more
>operations to be performed on an indicated resource prior to
>digest calculation. (These operations are different from those specified in
>the
><code>signature</code>; those are are applied over <code>signedinfo</code>.)
>
>If the <code>Transformations</code> element is omitted, the only operation
>performed is the default object canonicalization algorithm. </p>
I believe consensus was no transformation. If some default
canonicalization was applied, it would have to be data type dependent
since even minimal canonicalization doens't make much sense for, say,
a JPEG file.
><p>The <code>Transformations</code> element contains an ordered list
>of <code>Transformation</code> elements. The output of each
><code>Transformation</code> serves as input to the next
><code>Transformation</code>. The input to the first
><code>Transformation</code> is the raw data result of obtaining the
>resource given by <code>Location</code>.
>The output from the last <code>Transformation</code> is the input for the
>digest algorithm.</p>
I believe that encoding information should be input to the first
transformation and passed along, possibly changed by some
transformations.
><p class="xml-dtd"><!ELEMENT Transformations (Transformation+)></p>
>
><p>Each <code>Transformation</code> consists of an Algorithm attribute, an
>Encoding attribute, and content appropriate for the given
>algorithm. The Algorithm attribute value specifies the name of
>the algorithm to be performed, and the <code>Transformation</code> content
>is
>provided as additional data to govern the algorithm's processing
>of the input resource. If the Encoding attribute indicates that
>the <code>Transformation</code> content is base 64 encoded, then the
><code>Transformation</code> content will be base-64 decoded before it is
>presented to the transformation algorithm.</p>
I like this. Parameters are algorithm dependent. Usually there are
few parameters although some may have very rich internal structure.
I'm not sure we need a syntax for parameters.
><p class="xml-dtd"><!ELEMENT Transformation ANY><br>
><br>
><!ATTLIST Transformation <br>
><br>
>
>Algorithm CDATA #REQUIRED ><br>
><br>
> Encoding
>(urn:dsig:base64|urn:dsig:none) urn:dsig:none ><br>
><br>
><!-- The CDATA conforms to the productions specified by [URI] --> <br>
></p>
>
><p>Examples of resource transformations include but are not limited
>to base-64 decoding, canonicalization, XPath filtering, and XSLT.
>The generic definition of the <code>Transformation</code> element also
>allows
>application-specific transformation algorithms. For example, the
>transformation could be a decompression routine given by a base-64
>encoded Java class appearing in the <code>Transformation</code> content.
>However, applications should refrain from using application-specific
>transformations whenever possible since the resulting signature will not
>necessarily be verifiable outside of the application domain. The
>section <a href="#TransformationAlgorithms">Transformation Algorithms</a>
>defines the list of standard transformations.</p>
I'd prefer to state things positively, that if you use algorithms
enumered in the spec, or even better, those whose implementation is
specified as mandatory, you gain the best interoperability. If we put
a statement about this here, we need to check that we say essentially
the same thing about signature and digest algorithms in the
appropriate places.
><p class="comment">Implementation Comment: When transformations are applied
>the signer is
>not signing the native (original) document but the resulting (transformed)
>document that
>is not captured explicitly in the signature syntax. Where transformation
>processes are
>well known and widely implemented an application might include native
>content and specify
>transformations by reference. Otherwise, an application may perform
>transformations on the
>content itself and use the resulting content within the signature. </p>
I think I know what you are trying to say but I'm not sure it quite
says it. For example, the base64 of an "original" binary MPEG might
be included and the Transform used to retore it to its original form.
><p class="comment">Security Comment: Applications are recommended to ensure
>signers
>understand the actual resulting content that is being signed after
>transformations are
>applied. Users should not be tricked into signing a native content that is
>transformed
>into something that the user would not have signed otherwise. This
>recommendation applied
>to transformations specified in the signature block, as well as
>transformations found
>within the document itself. </p>
Comments along this line are definitely needed but should be in the
Security Considerations section. A reference to that section could be
included here.
>Changes to algorithm table in Section 7
>==========================
>
> <tr>
> <td>Transformation</td>
> <td> </td>
> <td> </td>
> <td> </td>
> <td> </td>
> </tr>
> <tr>
> <td> </td>
> <td>Canonicalization</td>
> <td>REQUIRED</td>
> <td>urn:dsig:c14n</td>
> <td>suggested W3C</td>
> </tr>
> <tr>
> <td> </td>
> <td>Base 64 Decoding</td>
> <td>RECOMMENDED</td>
> <td>urn:dsig:base64</td>
> <td>suggested W3C</td>
> </tr>
> <tr>
> <td> </td>
> <td>XPath Filtering</td>
> <td>RECOMMENDED</td>
> <td>urn:dsig:xpath</td>
> <td>suggested W3C</td>
> </tr>
> <tr>
> <td> </td>
> <td>XPointer Filtering</td>
> <td>RECOMMENDED</td>
> <td>urn:dsig:xpointer</td>
> <td>suggested W3C</td>
> </tr>
> <tr>
> <td> </td>
> <td>XSLT</td>
> <td>RECOMMENDED</td>
> <td>urn:dsig:xslt</td>
> <td>suggested W3C</td>
> </tr>
> <tr>
> <td> </td>
> <td>XSL Stylesheet</td>
> <td>RECOMMENDED</td>
> <td>urn:dsig:xsl</td>
> <td>suggested W3C</td>
> </tr>
> <tr>
> <td> </td>
> <td>Java Transformation</td>
> <td>OPTIONAL</td>
> <td>urn:dsig:java</td>
> <td>suggested W3C</td>
> </tr>
>
>First draft of section 7.6
>==========================
>
><h3 id="TransformationAlgorithms">7.6 Transformation Algorithms</h3>
>
><p>Application developers are strongly encouraged to support all
>transformations listed in this section as RECOMMENDED unless the
>application environment has severe resource constraints that would
>make such support impractical. The working group goal is to
>maximize application interoperability on XML signatures, and the
>working group expects ubiquitous availability of software to
>support these transformations that can be incorporated into
>applications without extensive development.</p>
>
><h4>7.6.1 Canonicalization</h4>
>
><p>The Algorithm value for canonicalization is urn:dsig:c14n.</p>
>
><p>The <code>Transformation</code> element content MUST be a
><code>Canonicalization</code> element, which specifies the
>canonicalization algorithm that will be applied to the input
>of the <code>Transformation</code> element. </p>
I think there will be few enough standard canonicalization algorithms
that they can have different algorithm values.
Null, Minimal, DOMcanon, W3Ccannon. DOMcanon might take a parameter
or have versions to determin (1) if it discards comments and (2) if
it discards Processing Instructions.
><h4>7.6.2 Base-64 Decoding</h4>
>
><p>The Algorithm value for the base 64 decoding transformation is
>urn:dsig:base64.</p>
>
><p>The base-64 decoding algorithm identifier is urn:dsig:base64.</p>
>
><p>The base-64 <code>Transformation</code> element has no content. The
>input (from the <code>Location</code> or from the previous
><code>Transformation</code>) is base-64 decoded.
>This transformation is useful if an application needs to sign the raw
>data associated with base-64 encoded content of an element.</p>
>
><h4>7.6.3 XPath Filtering</h4>
>
><p>The Algorithm value for the XPath filtering transformation is
>urn:dsig:xpath.</p>
>
><p>The <code>Transformation</code> element content MUST conform to
>the XML Path Language (<a href="#XPath">XPath</a>) syntax.</p>
>
><p>XPath assumes that an XML processor has processed the input
>resource. So, for example, entity reference expansion,
>normalization of linefeeds and attribute values are normalized,
>and CDATA section replacement are expected. As well, XPath joins
>all consecutive characters into a single text node.</p>
>
><p>The input resource MUST be a well-formed XML document. The result
>of applying the XPath to the input resource MUST be a node-set (as
>defined in <a href="#XPath">XPath</a>). The output of this
>transformation is a new XML document with the following
>characteristics:</p>
>
><ol>
><li>The output document has the XML declaration of the input
>resource (see rule 23 XMLDecl in <a href="#XML">XML specification</a>).
^ if any
>If the encoding is UTF-16, the output document has the same byte order
>mark as the input resource.</li>
>
><li>The output document contains the nodes in the node-set
>identified by the XPath, and excludes the nodes of the input
>resource that are not not in the node-set identified by the XPath.</li>
>
><li>The nodes in the output document appear in the document order
>(as defined in <a href="#XPath">XPath</a>) of the input resource.</li>
>
><li>The output document has all of the input resource's entity
>references expanded, except that characters corresponding to
>illegal XML are reencoded as character references
>(<a href="#XML">XML</a> rule 66) except the ampersand and less
>than symbol, which are encoded using &amp; and &lt;,
>respectively.</li>
>
><li>Attribute values are normalized in accordance with the rules
>for a validating XML processor (even if the implementation did not
>use a validating XML processor to parse the input resource).</li>
></ol>
>
><p>It is RECOMMENDED that the XPath be constructed such that the
>result of this operation is a well-formed XML document. This
>should be the case if root element of the input resource is
>included by the XPath (even if a number of its descendant elements
>and attributes are omitted by the XPath).</p>
The above it not enough to specify how the output is formed. Are
there any new lines?
><h4>7.6.4 XPointer Filtering</h4>
>
><p>The Algorithm value for the XPointer filtering transformation is
>urn:dsig:xpointer.</p>
>
><p>The <code>Transformation</code> element content MUST conform to the
>XML Pointer Language (<a href="#XPointer">XPointer</a>) syntax.</p>
>
><p>The processing rules for XPointer filtering are identical to those
>for XPath filtering (stated above), except that the additional
>functionality offered by XPointer can be utilized in constructing
>the output node-set.</p>
>
><p>The XPointer filter is particularly important if the input
>resource is processed by a validating XML processor since the
>XPointer barename shortcut could then be used to implement the
>well-known fragment identification by ID attribute.</p>
>
><p>NOTE: In application environments with severe resource
>limitations, applications MAY constrain XPointer support to
>barename processing and also to determination of the ID attribute
>by means other than a validating XML processor. In fact, the use
>of an XML processor for barename resolution is OPTIONAL. However,
>the output expectations of this transformation MUST be supported
>by the application.</p>
>
><h4>7.6.5 XSLT Transformation</h4>
>
><p>The Algorithm value for the XSLT transformation is urn:dsig:xslt.</p>
>
><p>The <code>Transformation</code> element content MUST conform to the
>XSL Transformations (<a href="#XSLT">XSLT</a>) language syntax.</p>
>
><p>The processing rules for the XSLT transformation are stated in the
>XSLT specification.</p>
>
><h4>7.6.6 XSL Stylesheet Transformation</h4>
>
><p>The Algorithm value for the XSL transformation is urn:dsig:xsl.</p>
>
><p>The <code>Transformation</code> element content MUST either conform to
>the
>Extensible Stylesheet Language (<a href="#XSL">XSL</a>) syntax or
>provide a single <code>Location</code> element whose URI content indicates
>an XSL stylesheet.</p>
>
><p>The processing rules for the XSL transformation are stated in the
>XSL specification.</p>
>
><p>This transformation is important for applications that would like
>to create a digital signature on the data as it was actually
>presented to the signer.</p>
>
><h4>7.6.7 Java Transformation</h4>
>
><p>The Algorithm value for the Java transformation is urn:dsig:java.</p>
>
><p>Details to be determined.</p>
>
><p> Although the Algorithm attribute of a <code>Transformation</code>
>can take application-specific values, having a Java transformation seems
>to be the most reasonable way to allow application-specific
>transformations that can be processed outside of the application
>domain.</p>
Thanks,
Donald
Received on Tuesday, 12 October 1999 08:16:57 UTC