Re: Soap Message Canonicalization (SM-C14N)

Agreed, this is a good start. Thanks for starting this.
It could use some examples to demonstrate before and
after examples (XML-C14N[1] does this).

I agree with Henrik regarding his comments on lexical ordering
[2]. This may require a little more noodling.

Another consideration we need to give here is that while the
SOAP spec is written in terms of XML Infoset, XML-C14N is not.
It is written in terms of XML1.0 serialization using terms such
as "node". I think that when we talk about a SM-C14N algorithm that
we have two questions we need to ask ourselves:
	1) do we want to define SOAP c14n in terms of Infoset so that
	it applies to all possible serializations?
	2) does this c14n algorithm apply exclusively in terms
	of XML1.0 serializations of the Infoset?

I'm not sure I'm convinced of the correct answer to either.

More comments below.

Cheers,

Chris

Rich Salz wrote:

> Here's my action item to write up how to canonicalize SOAP messages.
> I'm basing it on Henrik's proposal for what message rewrites are allowed [1].
> 
> In doing so, I came across a problem.  The proposal allows an intermediary
> to remove the actor attribute if it's targeted to the ultimate recipient.
> If this remains, it means that only entities that know the recipient can
> verify a signature.  Speaking as someone who sells generic DSIG servers,
> I think that's a mistake. :)  I see three choices (in my decreasing order
> of preference):
> 1   Remove that from the proposal
> 2   Require a "parameter" to the SM-C14N so the recipient can be
>     identified.  E.g., in an XML DSIG you'd have a transform like this:
> 	<disg:Transform disg:Algorithm="[[value; see below]]">
> 	    <soap-env:ultimateRecipient>uri...</soap-env:ultimateRecipient>
> 	</disg:Transform>
> 3   Limit verification to those who know the recipient
> 
> Reaction?
> 
> Second, since intermediaries can add and remove headers, it's necessary
> to define an ordering.  I chose alpha-order, as that will often not
> require the full rendering of all elements to be buffered.
> 
> Anyhow, my proposed text appears below.  The prose is a little turgid,
> sorry.
> 	/r$
> 
> [1] http://lists.w3.org/Archives/Public/xml-dist-app/2002Feb/0183.html
> 
> 
> Soap Message Canonicalization (SM-C14N)
> ---------------------------------------
> 
> Because intermediaries have some flexibility in serializing messages that
> pass through them, it is necessary to define a canonicalization method so
> that all semantically equivalent serializations will render identically.
> This is necessary, e.g., to generate a message digest for a digital
> signature, maintain a replay cache, and so on.
> 
> This mechanism is called SOAP Message Canonicalization (SM-C14N).
> It is identified by the following URI: [[value needed]].  SM-C14N can be
> targetted at an individual header or body element, a set of such elements,
> or an entire SOAP message.
> 
> When targetted to an individual element information item, the following
> steps are performed:
> 1.  Any namespace declarations that are inherited from the outer SOAP
>     element, and used within the element, are treated as if they were
>     declared by the element.


This will be "undone" by the XML-C14N algorithm because it ignores
all namespace nodes for which the parent element has the same namespace
in scope.


> 2.  if the SOAP mustUnderstand attribute information item is present
>     with a non-false value, the value is taken to be "1"


I think that we need to be explicit and say 'with a value of "true"'


> 3.  if the SOAP mustUnderstand attribute information item is present
>     with a false value, the attribute information item is ignored


Same here: 'with a value of either "false" or "0"...'. Also, if we
characterize this in terms of a transform, then we should be explicit
and say that the attribute node is removed.


> 4.  if the SOAP actor 
> The element is then processed according to XML-C14N.


See above, this may be trickier than we first thought!


> 
> When targetted to multiple element information items, each is processed
> as described above.  The elements are then sorted lexigraphically,
> and a single newline (&#A) is inserted between each one.
> 
> When targetted to a SOAP Header or Body element information item, the
> result is computed as if the canonicalization was applied only to all
> the immediate child elements of the SOAP element.  Note that the SOAP
> Header or Body element information item itself is not directly used.
> 
> When targetted to a SOAP message information item, the result is
> calculated as the concatenation of targetting the SOAP Header element
> information item, a single newline, and targetting the SOAP Body element
> information item.  Note that the SOAP Message element information item
> itself is not directly used.
> 	-30-
> 
> 
> 


[1] http://www.w3.org/TR/2001/REC-xml-c14n-20010315
[2] http://lists.w3.org/Archives/Public/xml-dist-app/2002Feb/0268.html

Received on Friday, 15 February 2002 14:40:12 UTC