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

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

Okay, I'm not proposing the spec would get into any of these details.
I'm just proposing adding "and validation of those expressions by
receivers".  That text would be added to security considerations, so it
is just information to help implementers and isn't normative.
Implementers would have to do the study to see exactly what kind of
validation they need to make their implementation secure.  If we want to
expand that into the four bullets I listed, that is fine with me too.  I
think it would still just be guidance on the kinds of validation needed
for that option and implementers would have to study how to apply that
guidance and that option to their implementation securely.

&Thomas.

] -----Original Message-----
] From: Duane Nickull [mailto:dnickull@adobe.com]
] Sent: Friday, June 17, 2005 1:01 PM
] To: DeMartini, Thomas
] Cc: wss@lists.oasis-open.org
] Subject: Re: [wss] Issue 399: Proposed Security Consideration Text
] 
] This may be problematic.    If I ask the API to an XPath class to
] execute an XPath instance against an XML instance, it may return
] something [null] or a real node value.  In Java, it might come down to
] writing the exact code for this.  As stated in the J2EE JavaXpath API
spec
] 
] "The arguments, |null| is a valid value"
] 
] It also throws an XPathFunctionException
] 
] This inevitably comes down to someone being careful enough to write
] 
] if ((this.representations != null) &&
] (this.representations.equals("theNodeValue") {//do something}
] 
] I feel it all comes down to implementation issues which may be better
] address in WS-I or even a WSS TC interoperability profile
recommendation.
] 
] Having said that, I am still a newbie in this TC and don't have a feel
] for the desired level of technical constraints WRT this issue.
] 
] My $0.02 worth
] 
] Duane
] 
] 
] DeMartini, Thomas wrote:
] 
] >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
] >* checking that the reference uri points to the soap:Envelope
] >* checking that the xpath resolves to something in the soap:Envelope
] >* checking that the thing the xpath resolves to is canonically
] >equivalent to the post-transform result of the reference
] >
] >&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.ph
p
] >>>
] >>>
] >] >>
] >] >>
] >] >] >
] >] >] >
] >] >] >
] >] >]
] >] >]
] >---------------------------------------------------------------------
] >] >] 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
] >>
] >>
] >] >
] >] >
] >] >
] >
] >