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 18:38:53 UTC