Re: Soap Message Canonicalization (SM-C14N)

The archives for the group were closed for some reason; this link
should now work.

Cheers,



On Sat, Feb 16, 2002 at 10:20:09AM -0800, Mark Nottingham wrote:
> 
> 
> 
> [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/
>  
> 

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

Received on Saturday, 16 February 2002 19:52:31 UTC