RE: [wss] Issue 399: Proposed Security Consideration Text

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

"My" position?  I have a position?

I'm just trying to accurately capture the first alternative proposed for
the security consideration section.

Recall that the following 4 alternatives were proposed for the security
consideration section:
Alternatives countermeasures include (but are not limited to):
1. References using XPath transforms with Absolute Path expressions,
2. A Reference using an XPath transform to include any significant 
location-dependent elements and exclude any elements that might 
legitimately be removed, added, or altered by intermediaries,
3. Using only References to elements with location-independent 
semantics,
4. Strict policy specification and enforcement regarding which 
message parts are to be signed. For example:
 * Requiring that the entire SOAP Body and all children of 
SOAP Header be signed,
 * Requiring that SOAP header elements which are marked 
MustUnderstand="false" and have signed descendents MUST include the 
MustUnderstand attribute under the signature.

I think 2 and 3 are clear.  I have some concerns with 4, but I don't
have any better text to suggest, so I'm going to let that one go.

I think 1 doesn't clearly capture the alternative discussed in the many
e-mail threads leading up to this proposal.

Accordingly, I am suggesting changing 1 to read as follows:
1. References using XPath transforms with Absolute Path expressions and
validation of those expressions by receivers including
 * checking that the URI for that reference resolves to the enclosing
document (initial context node),
 * checking that the Absolute Path XPath expression evaluates from
the initial context node to the digested nodeset.

So I am asking if you also agree that the revised #1 better captures the
discussed alternative, or if you could propose rewording of #1 that
better captures the discussed alternative.

Another wording I think captures it also is:
1. References using XPath transforms with Absolute Path expressions and
checking by the receiver that the URI and Absolute Path XPath expression
evaluate to the digested nodeset.

If you're not happy with either of the above rewordings, I'm open to
other suggestions that better capture the discussed alternative.  I just
think the wording in the proposal for alternative #1 doesn't have enough
details to understand the alternative.

&Thomas.

] -----Original Message-----
] From: Michael McIntosh [mailto:mikemci@us.ibm.com]
] Sent: Monday, June 20, 2005 1:27 PM
] To: DeMartini, Thomas
] Cc: Duane Nickull; wss@lists.oasis-open.org
] Subject: RE: [wss] Issue 399: Proposed Security Consideration Text
] 
] "DeMartini, Thomas" <Thomas.DeMartini@CONTENTGUARD.COM> wrote on
] 06/20/2005 02:42:34 PM:
] 
] > Mike, my four bullets were just trying to guess at what you meant.
] > Given what you say below, let me try to test my understanding again.
] > Would the following statement be consistent with what you mean?
] >
] > References using XPath transforms with Absolute Path expressions and
] > validation of those expressions by receivers including
] > * checking that the URI for that reference resolves to the enclosing
] > document (initial context node),
] > * checking that the Absolute Path XPath expression evaluates from
] > the initial context node to the digested nodeset.
] 
] Now I THINK I understand your position. You are talking about policy
] enforcement.
] In that context I think your concept of "validation" translates to:
] * checking that the resulting nodeset is allowed or required to be
signed.
] 
] I think this policy check needs to be performed by all receivers
] regardless of whether they use XPath expressions or not.