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

[Duane Nickull <dnickull@adobe.com>]

I'm cool with that.  Sounds like a job for WS-I BSP.

D

DeMartini, Thomas wrote:

>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
>>>      
>>>
>] >>
>] >>
>] >] >
>] >] >
>] >] >
>] >
>] >
>  
>