OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-sx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: REVISED Proposal: i018 Absolute XPath expressions


Revised Proposal: 

Note: Line numbers are form the version @ 
http://www.oasis-open.org/apps/org/workgroup/ws-sx/download.php/17050/ws-securitypolicy-1.2-spec-ed-01-r04.doc

Append the following to the list of algorithm suites (@line 1276):
        "[Abs XPath] Absolute Path XPath Expression"

Append the following to the table of abbreviations and algorithm URIs 
(@line 1277):
        "AbsXPath http://http://docs.oasis-open.org/...TBD.../AbsXPath";

Insert the following to the list of algorithm suites (@line 1390):
        "<sp:AbsXPath ... />"

Append the following to the list of algorithm suites (@line 1444):
        "/sp:AlgorithmSuite/wsp:Policy/sp:AbsXPath
        This assertion indicates that the [XPath] property is set to 
'AbsXPath'."

Thanks,
Mike

Michael McIntosh/Watson/IBM@IBMUS wrote on 02/07/2006 05:15:08 PM:

> Signed XML re-writing attacks take advantage of the position 
independence 
> (you can move the target element and the reference still resolves) of 
> IDREF signature references. The sp:OnlySignEntireHeadersAndBody 
assertion 
> can help prevent these attacks when only the soap:Body and children of 
the 
> soap:Header element are to be signed. However, when other elements are 
> referenced in a signature it may be necessary to use a position 
dependent 
> reference mechanism such as an absolute path XPath expression. For a 
> detailed explanation of this issue see:
> 
> http://domino.research.ibm.com/library/cyberdig.
> nsf/papers/73053F26BFE5D1D385257067004CFD80/$File/rc23691.pdf
> 
> Note that not this example XPath expression uses an absolute path:
>         a) /soap:Envelope/soap:Header/wsa:ReplyTo
> and this example does not use an absolute path:
>         b) //wsa:ReplyTo
> While all elements resulting from evaluating "a" are also returned by 
> evaluating "b", the reverse is not necessarily true. "b" does not 
protect 
> against the element being moved after it is signed.
> 
> Proposal
> 
> Before Line 606 Add:
> 
> /sp:SignedParts/sp:Header/@UsePositionalReference
> This optional attribute indicates that the specified SOAP header element 

> must be integrity protected in a way that prevents repositioning the 
> element in the message. If this attribute is "1" (true) and XML 
Signature 
> is used to protect the integrity of the element, the reference must use 
an 
> absolute path XPath expression. If this attribute is not specified the 
> default is "0" (false).
> 
> Before Line 626 Add:
> 
> /sp:SignedElements/@UsePositionalReference
> This optional attribute indicates that the specified element(s) must be 
> integrity protected in a way that prevents repositioning the element(s) 
in 
> the message. If this attribute is "1" (true) and XML Signature is used 
to 
> protect the integrity of the element(s), the reference(s) must use an 
> absolute path XPath expression. If this attribute is not specified the 
> default is "0" (false).



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]