Re: Soap Message Canonicalization (SM-C14N)

Hi Rich,

You partially motivate this with caching. I'm not sure that it really
helps there, though; the problem that caching faces is identifying
the parts of a request message that are used to compose a cache key.

As such, the variety of semantically equivalent section 5 encodings
(see [1]) is much more of a problem than block ordering, namespace
inheritence, etc., which can mostly be taken care of through use of
XML-aware tools.

I'd suggest dropping caching from the motivations for this effort,
and an issue re: section 5 canonicalisation (there may be other ways
to compose the cache key from a section 5-encoded message, but I
still think it would be useful).


On Fri, Feb 15, 2002 at 10:59:25AM -0500, 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]
> 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.
> 2.  if the SOAP mustUnderstand attribute information item is present
>     with a non-false value, the value is taken to be "1"
> 3.  if the SOAP mustUnderstand attribute information item is present
>     with a false value, the attribute information item is ignored
> 4.  if the SOAP actor 
> The element is then processed according to XML-C14N.
> 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-

Mark Nottingham

Received on Saturday, 16 February 2002 13:19:34 UTC