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

I agree with many of the concerns put forward here.

I suggest a slightly different approach to C14N, fragments etc.
Where there are multiple signatures over different fragments of
the document for the purposes of signing, consider each signature
in isolation.

For the purposes of compact transport of the document and attached
signatures consider a packaging format.

This approach requires a data transformation to recover a
particular signing view from a complex, multi-signed document.
Such a transformation would take a parameter (the view to be
extracted) and is not therefore a C14N algorithm.

		Phill


> -----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 6: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 Friday, 20 August 1999 13:55:40 UTC