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

Re: Proposal for resolution of issue 176

From: Marc Hadley <marc.hadley@sun.com>
Date: Tue, 12 Feb 2002 11:16:32 +0000
Message-ID: <3C68F990.7090805@sun.com>
To: Christopher Ferris <chris.ferris@sun.com>
CC: Henrik Frystyk Nielsen <henrikn@microsoft.com>, Noah Mendelsohn <noah_mendelsohn@us.ibm.com>, xml-dist-app@w3.org
We also need to consider the impact of the suggested rules laid out for 
intermediaries rewriting the values of header attributes, eg. removing 
mU="false" attrs.

What I think we *really* need is a SOAP message canonicalisation 
algorithm. The suggested resolution goes part of the way, but I think we 
need something much more rigourous.

The algorithm would need to include rules for protecting whitespace, 
comments, PIs etc inside blocks and ignoring whitespace etc between 
blocks. It would also need to define a canonicalisation transform for 
SOAP attributes.

Marc.

Christopher Ferris wrote:

> Actually, you can sign the entire message/envelope and
> exclude those element info items which are subject to
> removal by intermediaries either by means of inclusion or
> exclusion. For instance, I might sign all but the SOAP Header
> blocks that have an actor attribute, thus preserving the
> signature from sender to ultimate recipient. Equally, I might
> sign the envelope, excluding all but a set of listed header
> blocks that I wish to be signed so as to ensure that in
> addition to the header blocks, the envelope element
> information item itself were the same as was sent, etc
> (so that a MITM couldn't much with namespace decls, etc.
> as might be held within the envelope info item and its
> direct children).
> 
> Cheers,
> 
> Chris
> 
> Henrik Frystyk Nielsen wrote:
> 
>> Maybe I am misinterpreting your mail but the premise seems to be that it
>> should be possible to sign a complete SOAP message from top to bottom
>> and have that signature survive SOAP processing through the complete
>> message path. Unless we only envision SOAP receivers to be strict
>> tunnels then I strongly doubt that this will be a realistic scenario.
>> For example, it doesn't seem to match the very possibility that header
>> blocks may be inserted.
>>
>> I think a more likely scenario is that one signs specific header blocks
>> and the body, say, but not the entire envelope. I agree that we have to
>> be clear on what SOAP nodes can rely on but I think the proposed text
>> does provide strict rules for what is allowed and hence also provides
>> guidelines for what is good to sign.
>>
>> Henrik Frystyk Nielsen
>> mailto:henrikn@microsoft.com
>>
>>
>>> This point should be capable of being addressed by Infoset. Character 
>>> info items belong to (have as a property) a parent element 
>>> information item (at least as I understand it). Thus, we could say 
>>> that when removing an element information item or inserting a new 
>>> element info item, that the characeter info items which are not 
>>> parented by said element info item SHALL NOT be disturbed or possibly 
>>> SHALL be preserved. We would probably need to also say that no 
>>> character information items may be added/removed to/from a the 
>>> following parent element information items:
>>>     Envelope
>>>     Header
>>>     Body
>>> by an intermediary.
>>>
>>> The issue of removed and reinserted SOAP header element info items
>>> (blocks) becomes more relevant because technically, it is not the 
>>> same element information item as was received. By that, we absolve an 
>>> intermediary from having to necessarily preserve the whitespace, etc. 
>>> as might have been included in the removed element. We have also made 
>>> it crystal clear that because it is technically a new element 
>>> information item that has been inserted into the message/envelope 
>>> that no claims can be made that apply end-to-end with regards to 
>>> these SOAP header element info items (blocks) because the SOAP 
>>> process model states that they MUST be removed.
>>>
>>> That seems to me to be the safest approach.
>>>
>>
> 
> 


-- 
Marc Hadley <marc.hadley@sun.com>
XML Technology Centre, Sun Microsystems.
Received on Tuesday, 12 February 2002 06:16:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:06 GMT