Re: SOAP Message Canonicalization

Hi Joseph,

Thanks for you thoughtful comments, responses and questions 
interspersed below.

On Thursday, Jan 9, 2003, at 15:25 US/Eastern, Joseph Reagle wrote:

>
>> 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>
>
Would there be any value in specifying both a distinct transform and a 
canonicalization algorithm ? There would be very little extra work to 
do this (probably just defining a couple of extra URLs) and it might 
address the potential problems you describe below.

> 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.
>
OK, easily fixed.

> 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...?)
>
IIRC, the working group wanted to use the standard simple schema types 
where possible. Even if this were fixed we would still have to 
normalize 'defaulted' attribute values, processing instructions and 
whitespace.

> 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.
>
Thanks for pointing that out. I don't think the errata results in any 
changes being required though or did I miss something ?

Regards,
Marc.

--
Marc Hadley <marc.hadley@sun.com>
Web Technologies and Standards, Sun Microsystems.

Received on Friday, 10 January 2003 10:54:57 UTC