Re: Soap Message Canonicalization (SM-C14N)

Noah,

Some comments on your concerns below.

Cheers,

Chris

Noah Mendelsohn wrote:

> Thank you for undertaking this.  I must say, I'm nervous about some aspects
> of this.  Some concerns:
> 
> * While SOAP, in the absence of extensions, mandates no interpretation of
> header order, we have already made clear that extensions can be created to
> control processing order, and I think it's highly desireable that lexical
> order in the infoset be significant if the extension says so.  Consider
> streaming of large documents;  I think it should be possible to define
> control headers that will be known to appear early in the document.  I know
> that in many cases it will be the body that will be streamed, but that
> doesn't work well if you want to intermix control with data in a stream.
> Bottom line:  XML Infoset says lexical order is significant.  We could say
> that it's insignificant in SOAP, but I would prefer not to go that way.


I think that what needs to be made *crystal* clear is that the SM-C14N
algorithm should be reserved *strictly* for purposes of (re)producing
a steam of bits that can be digested for purposes of signing. I think
that for pusposes of de/encryption it might prove disasterous because
it would corrupt lexical ordering, which as you correctly point out
*may* have significance.

SM-C14N should also (IMO) *never* be used for purposes of producing
a byte-stream for transmission on the wire for the same reasons
as cited for XML-Enc above.


> 
> * Related concern:  you've suggested an ordering based on the entire
> contents of each header block, I think. That sounds extremely expensive to
> compute in the general case.  It could involve sorting on almost the entire
> contents of evey header element.


+1, this had me concerned as well.


> 
> * Requiring alphabetical order clearly conflicts with streaming;   you
> don't know the first header block until you've seen them all.


See above, but I gather that here the issue is also relevant for
implementations that want to stream the source for purposes of
producing a c14n'ed stream of bytes (not necessarily for the wire).


> 
> * In general, I'm not sure we've motivated a single canonicalization for
> SOAP.  What are the use cases.  Allowing some freedom to intermediaries
> does establish equivalence classes for soap messages, but not necessarily
> one representation for each class that's considered canonical.
> 
> Overall, my intuition is that the latitude given to intermediaries in
> rewriting a message should be relatively modest.  My starting point would
> be that the message goes through intact, except for removed and inserted
> headers.   I would, if necessary, loosen up the bare minimum needed to
> support efficient implementations.  I'm not convinced that reordering the
> headers is going to do anything other than limit the scenarios in which
> SOAP can be used, and introduce interop headaches (because some
> intermediaries will reorder and some won't).


+1


> 
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------
> 
> 
> 
> 
> 
>

Received on Monday, 18 February 2002 08:45:48 UTC