- From: David Burdett <david.burdett@commerceone.com>
- Date: Sun, 10 Oct 1999 22:28:12 -0700
- To: John Boyer <jboyer@uwi.com>
- Cc: DSig Group <w3c-ietf-xmldsig@w3.org>, jboyer@csr.csc.UVic.CA
John
In your new draft you say ...
"Location only permits a URI, and fragment identification is covered under
Transformations."
I'm wondering how your proposal would support the requirement where **all**
you want to be able to do is refer, by use of its ID attribute, to a
fragment of a XML document that consists of the standard canonical form of
an element and all its dependent children.
The way (I think) you are suggesting that requires the use of
Transformations seems complex to me.
Thoughts?
David
-----Original Message-----
From: John Boyer [mailto:jboyer@uwi.com]
Sent: Saturday, October 09, 1999 11:39 PM
To: Joseph M. Reagle Jr.; Donald E. Eastlake 3rd; David. Solo@Citicorp.
Com; jboyer@csr.csc.UVic.CA
Cc: DSig Group
Subject: First draft of Section 7.6 and proposed sections 4.3.1 and
4.3.3
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>
<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>
<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>
<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>
<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>
<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>
<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>
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>
<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 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>
<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>
Received on Monday, 11 October 1999 01:33:56 UTC