RE: [wss] Recently discover WSS security threat

[Rich Salz <rsalz@datapower.com>]

> Tell me, which of these steps says, "Verifies that the data object to be
> digested is located at the place indicated in the ds:Transform element?"

The semantics of the XPath transform.  If I ask for
	/soap:Envelope/soap:Header/tns:Foo[wsu:id='foo']
then I can be absolutely positive that the nodeset being referenced
is the tns:Foo element that is a direct child of the SOAP header.
I can write a similar, simple, XPath transform to be sure of signing the
SOAP body.

> The implementation I'm thinking of gets a message in to the security
> layer, finds the appropriate signature according to application policy,
> verifies that signature, making sure that the digest method used in
> 3.2.1.2.2 and signature method used in 3.2.2.2 satisfy application
> policy, and finally forwards to the application layer A) an array of the
> data objects used in 3.2.1.2.1 and B) the keying information used in
> 3.2.2.1.  It then throws everything else away, so as not to contaminate
> the application.

Ahh... now I understand your viewpoint.

I don't think doing things this way holds up.  For example, suppose
a signature comes in that includes an XSLT transform.  Do you
then forward the result of running the XSLT instead of the data
that's actually in the message?  Do you strip out the unsigned data?
Suppose I'm signing just the first child element of the soap body:

    <soap:Envelope>
      <soap:Body>
        <tns:wrapper>
            <tns:signthis wsu:id='xxx'>
            ...
            </tns:signthis>
            <tns:dontsignthis>
            ...
            </tns:dontsignthis>
        </tns:wrapper>
      <soap:Body>
    <soap:Envelope>

What do you return to the client?  Do you remove the tns:signthis element
from the body? include once in the "signed" array and then again "unsigned"
object array?  What about multiple signers?

(I don't mean "you" specifically, of course, just that it's easier than
writing "the implementation you're talking about")

> It doesn't matter to me whether we use XPath or xmldsig-filter2 or just
> URI, as long as we can build applications that don't have to go mucking
> around in the original message trying to figure out the correspondence
> between the data objects that were signed and the possibly-different
> pre-transformed data and their respective locations in the message.

I don't think this is a requirement we have to meet.  If some
implementations return *only* the post transform data, then some
information will be lost -- we agree. Sometime "real soon now", I'd expect
some kind of policy data to specify what must be signed, and the security
layer to enforce that policy.  Until then, I don't see mandating a
particular form of signature to enable a particular form (a minority,
probably of one) of implementation.

        /r$

-- 
Rich Salz                  Chief Security Architect
DataPower Technology       http://www.datapower.com
XS40 XML Security Gateway  http://www.datapower.com/products/xs40.html