- From: Mark Nottingham <mnot@mnot.net>
- Date: Sat, 16 Feb 2002 10:19:32 -0800
- To: Rich Salz <rsalz@zolera.com>
- Cc: xml-dist-app@w3.org
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/
Received on Saturday, 16 February 2002 13:19:34 UTC