Comments on 28022000 draft: Canonicalization

XML-Signature uses canonicalization in two different contexts: 

   (a) A canonicalization method may be used to canonicalize the 
       serialization of the SignedInfo element. 

   (b) Canonicalization can also be employed by a transform changing
       the input for the reference message digest calculation.

If it is used like described in (a), the input for the canonicalization
is not really a XML document instance but well-formed xml for the
SignedInfo element. For that reason I see some problems if "Canonical XML"
is used as canonicalization algorithm:

  (1) Currently we assign the same algorithm URI for both the 
      canonicalization method and the transform using canonicalization
      (http://www.w3.org/TR/1999/WD-xml-c14n-19991115). This is a reference
      to the c14n working draft, which requires a complete XML document
      instance as input data for the described processing. While 
      this is no problem in the transform context (b), it is indeed
      one in context (a). No hint is given in the c14n working draft how
      processing could be done if only a part of an XML document instance
      forms the input for canonicalization.

      My suggestions:

          Define two different algorithm URIs: 

          One for the transform content (b) with the c14n working draft as
          its specification reference.

          A second one for the canonicalization context (a) and provide a
          detailled specification in XML-Signature how to process the input
          data which is the serialization of a XML element and not one of
          a document (Maybe like this: Produce a new document with a simple
          XML declaration and make the SignedInfo element this document's
          root element, perform canonicalization as described in the c14n
          working draft, and finally remove the enveloping document stuff
          again).

  (2) If canonicalization is used within context (a), I cannot see how the
      algorithm implementation could know about the character encoding of
      the input byte stream. The input is not a XML document, so autodetection
      cannot be employed. Moreover, no parameter can be specified for the
      character encoding which could guide the algorithm.

      My suggestions:

          If we provide a detailled processing specification as suggested
          in (1), this problem will be also solved.
                    

Gregor 
   
-- 
---------------------------------------------------------------
Gregor Karlinger
mailto://gregor.karlinger@iaik.at
Institute for Applied Information Processing and Communications
Austria
---------------------------------------------------------------