Re: Proposal for resolution of issue 176

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.
>>
>

Received on Monday, 11 February 2002 20:59:01 UTC