W3C home > Mailing lists > Public > xml-dist-app@w3.org > February 2002

RE: Soap Message Canonicalization (SM-C14N)

From: Henrik Frystyk Nielsen <henrikn@microsoft.com>
Date: Fri, 15 Feb 2002 08:59:26 -0800
Message-ID: <79107D208BA38C45A4E45F62673A434D067C7CEC@red-msg-07.redmond.corp.microsoft.com>
To: "Rich Salz" <rsalz@zolera.com>, <xml-dist-app@w3.org>


Thanks for the quick turn-around! I haven't had a chance to go through
your proposal but regarding the ultimate recipient actor, it is *only*
if it has the default value

	http://www.w3.org/2001/09/soap-envelope/role/ultimate (or

and not if it is any other value.

Regarding the ordering, I am not sure alpha ordering works as one can
have multiple instances of the same block in a message. 

Hope this helps,


>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 
>to remove the actor attribute if it's targeted to the ultimate 
>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]]">
>	</disg:Transform>
>3   Limit verification to those who know the recipient
>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.
Received on Friday, 15 February 2002 12:00:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:18 UTC