RE: [wss] Recently discover WSS security threat

["DeMartini, Thomas" <Thomas.DeMartini@CONTENTGUARD.COM>]

] -----Original Message-----
] From: Rich Salz [mailto:rsalz@datapower.com]
] Sent: Thursday, June 02, 2005 8:06 PM
] To: DeMartini, Thomas
] Cc: Michael McIntosh; Hal Lockhart; wss@lists.oasis-open.org
] Subject: RE: [wss] Recently discover WSS security threat
] 
] > 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 semantics of the XPath transform" is not one of the steps.
Therefore the answer is unresponsive to the question "which of these
steps".

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

Thank you for taking the time to write specific questions.  I will try
to answer them below.  I am still hopeful that someone will answer the
five questions in my message at
http://www.oasis-open.org/apps/org/workgroup/wss/email/archives/200506/m
sg00026.html.

] 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?

Yes, that is my reading of the DSIG spec.  It also seems to be the most
secure thing to do.

] Do you strip out the unsigned data?

Yes, that is one possibility.  (It might be made available through some
other channel for audit or something, but for all intents and purposes,
we can consider it stripped out, lost, thrown away, whatever.)

] 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?

If just the tns:signthis element is signed, then I return just the
tns:signthis element.

If the soap:Envelope, soap:Body, tns:wrapper, is also signed, then I
return the tns:signthis element inside the soap:Envelope, soap:Body, and
tns:wrapper.

] Do you remove the tns:signthis element
] from the body? include once in the "signed" array and then again
] "unsigned"
] object array?

I'm not sure exactly what you mean by "remove".  I return (a copy of)
the tns:signthis element as part of the signed array.  If there is any
other channel to get unsigned data, I suppose it'd just be a log of the
incoming message unaltered by security processing and wouldn't
differentiate between signed vs. unsigned data.

] What about multiple signers?

If the signatures are targeted for different recipients, then each
recipient just processes the one they care about.  Are you saying there
is a case where two signatures would be targeted to the same recipient
and that recipient would be acting on both signatures?  Could the return
value in that case just be an array of the return value in the
one-signature case?

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

Of course :-)

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

I'm unconvinced policy alone can solve this problem.