- From: Henrik Frystyk Nielsen <henrikn@microsoft.com>
- Date: Mon, 11 Feb 2002 23:20:39 -0800
- 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 UTC