RE: The feasibility of adding a transformation step before the canoni calization step

I agree that there might be an unbounded number of application specific
transformations.  However, I'd like us to be more careful about labelling
everything application-specific. We don't have a clear definition of this
term as it applies to signing XML.

XML is grammar that is almost totally devoid of lexicon.  Hence, the
interdependencies of XML elements are not defined except in the context of
applications.  Hence, signed XML must be able to deal with all of the types
of interdependencies that XML permits.  This is not an optional part of our
work because there is no option in XML that says the XML is not well-formed
if the order of the elements matters or if ancestor information percolates
down to descendant nodes (which is, of course, the case for namespaces).

I would appreciate it if those who think the problems of document closure,
ancestor information, and element order are application-specific would read
the scenarios document section 2.4, then explain why these issues are any
more application-specific than, say, having the ability to validate the hash
of an object without having to dig up and check the hash on the object
itself.

John Boyer
Software Development Manager
UWI.Com -- The Internet Forms Company


-----Original Message-----
From: w3c-ietf-xmldsig-request@w3.org
[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Ed Simon
Sent: Thursday, August 19, 1999 3:38 PM
To: 'w3c-ietf-xmldsig@w3.org'
Subject: The feasibility of adding a transformation step before the
canoni calization step


During today's teleconference, there were a number of examples mentioned
suggesting that some level of transformation needed to be an integral part
of the XML digital signature spec.  Eg.

* excluding certain sub-elements from being signed
* signing the content of elements but not the starting and ending tags
* ensuring unique identifiers when creating a composite document
  from fragments of external documents
* preserving context-information: eg. did element X have ancestor Y?

IFF (if and only if) the workgroup decides that transformations like the
above
need to be an integral part of the XML digital signature specification, I
would
propose that processing include an OPTIONAL transformation step before
the canonicalization step.  The syntax which would support this
could be something like:

<signature id="foo">
...
  <object>
  ...
    <content type="manifest">
      <manifest id="bar">
        <resource>
          <location> syntax.txt </location>
          <transformationAlg type="xsl"
             href="http://www.transforms_r_us.org/excludeThis.xsl"
             digestAlg="sha-1"
             digest="a23bcd43 "/>
          <c14nAlg type="identity"/>
          <digestAlg type="sha-1"/>
          <digest> a23bcd43 </digest>
        </resource>
      </manifest>
    </content>
  </object>
...
</signature>

I recognize some serious problems with the above:

1. My suspicion is that there will be numerous application-specific
    transformation needs.  In the current framework,
    application-specific details should be captured
    in the signed attributes not in the <object> element itself to keep
    the "core" signature as free from application-specific details as
    possible.  On the other hand, if transformation is critical to the
    calculation of the digital signature,
    it needs to be in the <resource> element.  Right?  Your thoughts please.


2. The above example sneaks in a covert "resource" within the attributes
    of the <transformationAlg> element.  Alternatively, I could have had
    the <transformationAlg> element referencing a second <resource>
    element, but I notice the DTD for the new syntax from David Solo,
    Barb Fox, and Richard Brown seems to allow one and only one
    <resource> element per signature.  In Richard Brown's original
    syntax, there was a <resources> element containing multiple
    <resource> elements.  I was surprized that there was not any
    extended archive discussion about this change.
    Or did I miss it?  Was it decided that multiple <resource>
    elements was an unnecessary complexity?

Regards, Ed

P.S.
I think mixing transformation into the canonicalization step
will not work out because there will likely be a large
number of application-specific transformations that
applications would want to do whereas I hope
the number of canonicalization algorithms can be kept to less than
half a dozen (eg. identity [no canonicalization],
lossy canonicalization [the current W3C proposal],
lossless canonicalization [like the current W3C proposal but with all
information loss, just whitespace neutralization]).

Received on Thursday, 19 August 1999 20:18:04 UTC