RE: [wss] Recently discover WSS security threat

[Rich Salz <rsalz@datapower.com>]

>  For example, if there is to be an agreement that
> "signatures will also be used for message structure validation" in the
> WSS space, then the WSS spec should define what "message structure
> validation" is and should also define that signatures (or messages?) are
> not fully valid for WSS unless they pass "message structure validation".

My expectations are much more modest, and as I first said, I don't
believe this is something we should address (now).

> a) What does the application see as the authentic data?
> b) 32 or 33?
> c) If a receiver follows the processing model you described, where does
> it
> determine that the 33 resides in the message?
> d) And what is its location-relationship to the soap:Body?

What is authentic data -- the word "authentic" doesn't appear in the
DSIG recommendation at all.  You mean what the signer signed?

At any rate, I don't see a requirement that a DSIG implementation
*has* to make that data available to a consuming application,
and therefore don't see a requirement on WSS to do this.
I could do an implementation that did a "post-verification infoset,"
adding [is-signed] and [transformed-signed-data] information items,
analogous to the why XSD adds typing and default-value information.

BTW, given XSLT forwards-compatible, function/element-available, and
xslt:fallback, I'd strongly discourage anyone from using the XSLT
transform.

Mandating a particular signature style, particularly when a large
portion of the industry seems to be moving in a policy-oriented
direction, seems premature.

(My previous reply was confused, I was treating the XSLT as another
dsig:Reference, not a Transform, so most of what I wrote makes no sense,
sorry.)

        /r$

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