Re: SOAP Message Canonicalization

Hi Marc, Martin and XMLP.

On Thursday 09 January 2003 11:18, Marc Hadley wrote:
> SOAP 1.2 intermediaries have some license when serializing messages
> that pass through them. Some of the permitted changes that an
> intermediary can make have the possibility of invalidating an XML
> signature dependent upon on the parts of the message that are signed.
> SOAP 1.2, Part 1, 2.7.4 SOAP Intermediaries and Relayed Infoset[1]
> describes the rules that intermediaries must follow when relaying a
> SOAP message and the interactions of these rules with XML signatures.

Yes, we noted this scenario:

   Two XML documents may have differing information content that is
   nonetheless logically equivalent within a given application context.
   Although two XML documents are equivalent (aside from limitations
   given in this section) if their canonical forms are identical, it is
   not a goal of this work to establish a method such that two XML
   documents are equivalent if and only if their canonical forms are
   identical. Such a method is unachievable, in part due to
   application-specific rules such as those governing unimportant
   whitespace and equivalent data (e.g. <color>black</color> versus
   <color>rgb(0,0,0)</color>). There are also equivalencies established
   by other W3C Recommendations and Working Drafts. Accounting for these
   additional equivalence rules is beyond the scope of this work. They
   can be applied by the application or become the subject of future
   specifications.
   http://www.w3.org/TR/2001/REC-xml-c14n-20010315#Limitations

> In addition, the XMLP WG is currently considering the attached document
> for publication as a WG Note. The document describes a SOAP specific
> canonicalization algorithm that extends exclusive canonicalization to
> normalize the transforms that SOAP intermediaries can perform on
> messages passing through them. We would very much appreciate your
> feedback on the attached document and also that of the XML Signature
> working group if appropriate.
>
> It has been suggested that the proposed algorithm might be better
> formulated as a transform to permit composition with other
> canonicalization algorithms in the future, any feedback you may have on
> this suggestion would also be appreciated.

A few comments, one of which is that I agree with the suggestion above. 

1. I think I would recommend this be a distinct transform (instead of 
incorporating exc-c14n within it). It would make the specification very 
straightforward (in fact, one could probably precisely specify and test 
your transform with an XSLT) and allows it to be combined with other 
canonicalizations. The result is a slightly more verbose Signature 
Reference (an additional line), but I like that explicitness as well:

<Reference
 URI="http://example.com/foo.html"> 
  <Transforms>
    <Transform Algorithm="http://www.w3.org/2002/11/sm-c14n"/>  
    <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> 
  </Transforms> 

The first argument against this is that of performance efficiency: if they 
are a single transform I could do both operations in a single pass-through. 
However, that can still be done as I believe people are already 
"looking-ahead" in the transform list and optimizing for well known 
transforms that appear together.

The second argument against this is you can't use this method as a 
SignedInfo CanonicalizationMethod -- which doesn't permit arbitrary 
transforms. However, I don't believe you're likely to find these SOAP 
constructs in a SignedInfo anyway?

2. Not that it matters much, but the convention for c14n and exc-c14n is 
that even the with comments URI has a '#' at its end.

3. Just curious, but how much of a demand was for these application 
variances, particularly "0" and "false." (Would seem easier just to choose 
one from the outset...?)

4. "This algorithm also takes an optional explicit parameter of an empty 
InclusiveNamespaces element with a PrefixList attribute. The value of this 
attribute is the same as specified in [EXCL C14N]." FYI: on this point 
there is an error in the Recommendation addressed by an errata:

http://www.w3.org/2002/07/xml-exc-c14n-errata#E02
E02 2002-10-03 (Error)
In section 4 Use in XML Security, the data type of the PrefixList attribute 
value is specified as NMTOKENS in both the DTD and Schema. This does not 
permit the occurrence of the '#default' token in the attribute value 
because of the "#" character. Consequently, the type of this attribute 
value should be CDATA in a DTD and/or xsd:string in a XML Schema.


Hopefully other folks in the xmldsig WG will have comments too.