[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-sx] Issue 98: Inconsistencies related to SignedParts/* assertion
Corinna, 1. It was felt that explicit text was needed WRT soap:Body to ensure that people did not interpret the assertion to mean 'sign the child (children) of soap:Body'. Colloquially, some people refer to the child (children) of soap:Body as 'the body of the message'. There doesn't seem to be a similar problem for header elements. When someone says 'sign the wsa:ReplyTo header' people seem to understand that it covers the wsa:ReplyTo element, it's attributes and content. That said, I'm not averse to including language similar to that for soap:Body in the description of the sp:Header element. 2. I'm not sure quite what you are asking. There is a boolean property, it has a default value of 'false'. To set it to 'true', put the sp:OnlySignEntireHeadersAndBody assertion in the policy. There is no assertion that sets the value of the property to 'false'. Note that this is by design. Let's say I have a boolean property [Foo], with a default value of 'false'. And an assertion m:SetFoo that sets the value to 'true'. There are two possible policies; <wsp:Policy/> and <wsp:Policy> <m:SetFoo/> </wsp:Policy> 3. The [Entire Header And Body Signatures] property exists to protect against XML rewriting attacks. It essentially tells the signature processor that all the references outside the wsse:Security header should be to elements that are either direct children of soap:Header or to the soap:Body itself. If this property is set to true the signature processor can raise an error if any references are found to elements that do not meet this constraint, thus limiting the ability of an attacker to 'hide' a header by moving it inside some other element. Not also that while SignedParts requires entire headers to be signed, SignedElements does not. 4. Does my answer to 3. above also address this item? Cheers Gudge > -----Original Message----- > From: Marc Goodner [mailto:mgoodner@microsoft.com] > Sent: 26 July 2006 23:32 > To: Corinna Witt; ws-sx@lists.oasis-open.org > Subject: [ws-sx] Issue 98: Inconsistencies related to > SignedParts/* assertion > > Issue 98. > > ________________________________ > > From: Corinna Witt [mailto:cwitt@bea.com] > Sent: Wed 7/26/2006 12:17 PM > To: ws-sx@lists.oasis-open.org > Cc: Marc Goodner > Subject: NEW ISSUE: Inconsistencies related to SignedParts/* > assertion > > > > PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD UNTIL > THE ISSUE IS ASSIGNED A NUMBER. > The issues coordinators will notify the list when that has occurred. > > Protocol: ws-sp > > http://www.oasis-open.org/apps/org/workgroup/ws-sx/download.ph > p/18837/ws > -securitypolicy-1.2-spec-ed-01-r07.pdf > > Artifact: spec > > Type: design > > Title: Inconsistencies related to SignedParts/* assertion > > Description: > > 1. Line 605-607 about /SignedParts/Body say "...the entire > body, that is > the soap:Body element, it's attributes and content, of the > message needs > to be integrity protected". Line 608-618 about > /SignedParts/Header don't > say anything about whether the entire header needs to be integrity > protected. > > 2. Compare line 1796-1798 about > /SymmetricBinding/Policy/OnlySignEntireHeadersAndBody "This assertion > indicates that the [Entire Header And Body Signatures] property is set > to 'true'." with line 1499-1500 from 6.6 [Entire Header and Body > Signatures] Property: "The default value for this property is > 'false'." > (same thing in asymmetric binding btw.) > > 3. Assuming both SignedParts/Body and SignedParts/Headers are 'entire > element' by default and OnlySignEntireHeadersAndBody is true > by default, > why do we need another assertion with the same default? > > 4. It seems like a limitation to switch the default for > 'entire element > integrity protection' for headers and body wholesale - even more so if > they turn out not to have the same default. > ______________________________________________________________ > _________ > Notice: This email message, together with any attachments, > may contain > information of BEA Systems, Inc., its subsidiaries and > affiliated > entities, that may be confidential, proprietary, > copyrighted and/or > legally privileged, and is intended solely for the use of the > individual > or entity named in this message. If you are not the intended > recipient, > and have received this message in error, please immediately > return this > by email and then delete it. > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]