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

RE: Proposal for resolution of issue 176

From: Henrik Frystyk Nielsen <henrikn@microsoft.com>
Date: Mon, 11 Feb 2002 23:20:39 -0800
Message-ID: <79107D208BA38C45A4E45F62673A434D0656AA02@red-msg-07.redmond.corp.microsoft.com>
To: "Christopher Ferris" <chris.ferris@sun.com>
Cc: "Noah Mendelsohn" <noah_mendelsohn@us.ibm.com>, <xml-dist-app@w3.org>

I absolute agree that it is potentially possible to sign the whole
message. My point is that I don't think this is a realistic scenario
given the SOAP processing model. SOAP provides a very modular approach
where application-defined data is isolated as computational units in
header blocks and/or as body contents. I can see very interesting
scenarios where one wants to sign these computational units. However, I
am not sure I can see interesting scenarios where one would want to sign
comments or whitespace before or after the envelope or outside these
computational units in general.

Signing has to be robust not only in scenarios where blocks are removed
from the SOAP envelope but also where they are added. I would not want
the addition of a simple tracing header block to break my signature, for
example.

Fundamentally the model of signing seems to be compatible with the SOAP
model but maybe not all variants of how signing may be achieved work
equally well. Maybe signing the whole message is one of them or are
there scenarios that I am not considering?

Henrik Frystyk Nielsen
mailto:henrikn@microsoft.com

>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).
Received on Tuesday, 12 February 2002 02:21:10 GMT

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