Re: Soap Message Canonicalization (SM-C14N)

[1] http://groups.yahoo.com/group/soap-opt/message/3



On Sat, Feb 16, 2002 at 10:19:32AM -0800, Mark Nottingham wrote:
> 
> 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).
> 
> Cheers,
> 
> 
> 
> 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] 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.
> > 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
> http://www.mnot.net/
>  

-- 
Mark Nottingham
http://www.mnot.net/

Received on Saturday, 16 February 2002 13:20:10 UTC