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

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

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.
 
&Thomas.

________________________________

From: Michael McIntosh [mailto:mikemci@us.ibm.com]
Sent: Mon 6/20/2005 6:15 AM
To: DeMartini, Thomas
Cc: Duane Nickull; wss@lists.oasis-open.org
Subject: RE: [wss] Issue 399: Proposed Security Consideration Text



Comments inline ...

"DeMartini, Thomas" <Thomas.DeMartini@CONTENTGUARD.COM> wrote on
06/16/2005 06:29:11 PM:

> I believe it is actually more than the latter.  "Validation" of the
> expression, as I understand it (Mike or Rich can perhaps clarify), would
> include at least the following steps:
> * checking that the xpath syntax is valid

How would this be different from processing performed for ANY transform?
What is the expected result when any signature element content contains
invalid data?
I would expect the signature to be considered to be invalid;
but that would also apply for:
Reference/@URIs that do not resolve,
*Method/@URIs that are not supported,
other Transform data that is not understood, etc.

> * checking that the reference uri points to the soap:Envelope

WSS allows signatures over data outside the envelope and I would expect
most transforms to operate over that data; the URI merely points to the
initial context node.

> * checking that the xpath resolves to something in the soap:Envelope

Same comment above.

Some mechanism must be in place for the receiver to determine whether the
right stuff is signed;
but that is also orthogonal to the issue of XPath vs. IDREF.

> * checking that the thing the xpath resolves to is canonically
> equivalent to the post-transform result of the reference

I am not %100 sure I understand what you intend here.
My opinion is that if the signer provides a signed reference including:
- a digest over a canonicalized nodeset,
- a URI that resolves to the enclosing document (initial context node),
and
- an Absolute Path XPath expression which evaluates to the digested
nodeset,
The signature will verify if and only if:
- the canonicalized nodeset is unchanged,
- the XPath expression is unchanged, and
- the path from the initial context node to the nodeset is unchanged.

Nothing other than currently specified functionality is required in order
for this to work.
If you disagree, please provide a scenario/example where a signature might
falsely verify.

There is no doubt that XPath expressions might be generated which evaluate
to a nodeset
other than that which was intended, an empty (or other constant) nodeset
for example;
but the normal checks to verify that what must be signed is signed and
what must not be
signed is not should address that case.

>
> &Thomas.
>
> ] -----Original Message-----
> ] From: Duane Nickull [mailto:dnickull@adobe.com]
> ] Sent: Thursday, June 16, 2005 3:22 PM
> ] To: DeMartini, Thomas
> ] Cc: wss@lists.oasis-open.org
> ] Subject: Re: [wss] Issue 399: Proposed Security Consideration Text
> ]
> ] I am unclear what the intent of 'validation' is.  Is it to ascertain
> ] that the XPath syntax itself is valid or that it actually resolves to
> ] something in the XML instance file.  Erros in the latter may happen
> but
> ] might not be the fault solely of the XPath statement.
> ]
> ] Duane
> ]
> ]
> ] DeMartini, Thomas wrote:
> ]
> ] >On this section, I also suggest adding "and validation of those
> ] >expressions by receivers" immediately after "References using XPath
> ] >transforms with Absolute Path expressions".
> ] >
> ] >&Thomas.
> ] >
> ] >] -----Original Message-----
> ] >] From: Duane Nickull [mailto:dnickull@adobe.com]
> ] >] Sent: Wednesday, June 15, 2005 10:56 AM
> ] >] Cc: wss@lists.oasis-open.org
> ] >] Subject: Re: [wss] Issue 399: Proposed Security Consideration Text
> ] >]
> ] >] My take(s) inline:
> ] >]
> ] >] Granqvist, Hans wrote:
> ] >]
> ] >] >Hi all, quite good text. Just some proof-reading comments:
> ] >] >
> ] >] >General comment: There seems to be too many capitalized words,
> e.g.,
> ] >] >Shorthand, References, Body, Absolute Path, Document, and so on,
> ] >which
> ] >] >are not found capitalized in the specs.
> ] >] >
> ] >] >
> ] >] >
> ] >] >>XML Signatures using Shorthand XPointer References (AKA
> ] >] >>IDREF) protect
> ] >] >>against the removal and modification of XML elements; but do
> ] >] >>not protect
> ] >] >>the location of the element within the XML Document.
> ] >] >>
> ] >] >>
> ] >] >
> ] >] >"the element" is undefined in this sentence. Should it be
> ] >] >"this element/these elements"?
> ] >] >
> ] >] >
> ] >] DN - I perceived this as referring to the "xml elements" noted just
> ] >] above it.  Grammatically correcting it to "the elements" would be
> ] >correct.
> ] >]
> ] >] >
> ] >] >
> ] >] >>Whether or not this is a security vulnerability depends on
> ] >] >>whether the
> ] >] >>location of the signed data within its surrounding context has
> any
> ] >] >>semantic import. This consideration applies to data carried
> ] >] >>in the SOAP
> ] >] >>Body or the Header.
> ] >] >>
> ] >] >>
> ] >] >
> ] >] >What does "...within its surrounding context has any semantic
> ] >] >import" mean?  Does it mean "has semantic imports within its
> ] >] >surrounding context?"  If so, what the heck does that mean? :)
> ] >] >Can we exemplify?
> ] >] >
> ] >] >The sentence is a bit heavy. Can it be rewritten to begin "Use of
> ] >] >IDREFs is a security vulnerability if the location of the
> referenced
> ] >] >signed data..."?
> ] >] >
> ] >] >
> ] >] DN - I think the concept here is "determinism".  If the schema
> itself
> ] >is
> ] >] deterministic, then there should be no problem however if the
> schema
> ] >is
> ] >] not and there are potential issues arising from that, to me that
> ] >] indicates a fault in the actual data model itself or the process
> ] >someone
> ] >] used to derive the schema from the data model.  Such is worthwhile
> ] >] noting but out of scope for rectifying in a this spec.  We cannot
> ] >] constrain people to write good schemas ;-)
> ] >]
> ] >] Cheers.
> ] >]
> ] >] Duane
> ] >]
> ] >] >
> ] >] >
> ] >] >>...
> ] >] >>
> ] >] >>
> ] >] >
> ] >] >
> ] >] >
> ] >] >>In the general case of XML Documents and Signatures, this
> ] >] >>issue may be
> ] >] >>
> ] >] >>
> ] >] >
> ] >] >Unclear what "this issue" relates to here.
> ] >] >
> ] >] >
> ] >] >
> ] >] >>resolved by signing the entire XML Document and/or strict XML
> Schema
> ] >] >>specification and enforcement. However, because elements of the
> SOAP
> ] >] >>...
> ] >] >>
> ] >] >>
> ] >] >
> ] >] >Strict schema checking won't catch all SOAP header wrapping
> attacks
> ] >] >outlined in email threads/TC calls (I believe), so "and/or" seems
> too
> ] >] >loose, but I may be way off here.
> ] >] >
> ] >] >Thanks,
> ] >] >Hans
> ] >] >
> ] >]
> >---------------------------------------------------------------------
> ] >] >To unsubscribe from this mail list, you must leave the OASIS TC
> that
> ] >] >generates this mail.  You may a link to this group and all your
> TCs
> ] >in
> ] >] OASIS
> ] >] >at:
> ] >]
> ] >
> ] >
> ]
> >>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> ] >>
> ] >>
> ] >] >
> ] >] >
> ] >] >
> ] >]
> ] >]
> ---------------------------------------------------------------------
> ] >] To unsubscribe from this mail list, you must leave the OASIS TC
> that
> ] >] generates this mail.  You may a link to this group and all your TCs
> in
> ] >] OASIS
> ] >] at:
> ] >]
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> ] >
> ] >
> ] >---------------------------------------------------------------------
> ] >To unsubscribe from this mail list, you must leave the OASIS TC that
> ] >generates this mail.  You may a link to this group and all your TCs
> in
> ] OASIS
> ] >at:
> ]
> >https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> ] >
> ] >
> ] >
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in
OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>