RE: [wss] Recently discover WSS security threat

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

] > "The semantics of the XPath transform" is not one of the steps.
] > Therefore the answer is unresponsive to the question "which of these
] > steps".
] 
] Okay.  MU -- unask the question.    I don't think the layer between
] signature-code and application code must be restricted to those two
steps.

I think this is a good point, as it highlights that what we are really
talking about here is another kind of validation beyond the two core
validation steps in the DSIG spec (reference validation and signature
validation).  Let's call this additional kind of validation "message
structure validation".

I think the discussion has been between two points of view: what I've
been saying that "using only core validation there is only one way to
sign things to get what we want" and what you and Mike have been saying
that "we'd rather sign things in a different way and have an agreement
that signatures will also be used for message structure validation".

Personally, I am not opposed to the later point of view, so long as we
all understand the importance of what is going on and act on it
accordingly.  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".
(We would need to work out and get agreement on the details; this is
just a high-level description.)

] >
http://www.oasis-open.org/apps/org/workgroup/wss/email/archives/200506/m
] > sg00026.html.
] 
] My answer to your questions would be
] 	Yes, that works, but I don't think it's necessary since it's
very
] complex, not required, and seems to be based on a specific information
] model.

Thanks, this answers the first of my questions in that message.  What
about the other four?

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?

(These are examples of the details we'd need to work out in defining
"message structure validation".)

] > ] 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.
] 
] My view is that this runs counter to "see what is being signed,"
section
] 8.1.3, http://www.w3.org/TR/xmldsig-core/#sec-See.

Are you referring to "Just as a user should only sign what he or she
'sees,' persons and automated mechanism that trust the validity of a
transformed document on the basis of a valid signature should operate
over the data that was transformed (including canonicalization) and
signed, not the original pre-transformed data."?

It says "the data that was transformed...*not* the original
pre-transformed data."

"The result of running the XSLT" sounds to me like the "data that was
transformed."  "The data that's actually in the message" sounds to me
like "the original pre-transformed data".

So when I say I would return "the result of running the XSLT" and not
the "data that's actually in the message", why do you say that runs
counter to the DSIG spec that says "the data that was transformed...not
the original pre-transformed data"?

&Thomas.