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: RE: [ws-sx] Issue 98: Inconsistencies related to SignedParts/* assertion


Hi Gudge, 

1. I'd like to see language added as you suggested, since I don't quite
follow the interpretation you mentioned - I obviously have problems
interpreting the text as it is now.

(on the 08/02 call issue 98 was moved to 'editorial' to address this)

2. Ok, I missed that. Thanks for explaining.

3./4. Ok - what happens if the Integrity Assertions and
OnlySignEntireHeadersAndBody contradict each other?  (on the call it was
agreed that if there's need to address this, a new issue should be
raised)

Corinna

-----Original Message-----
From: Martin Gudgin [mailto:mgudgin@microsoft.com] 
Sent: Thursday, July 27, 2006 3:25 AM
To: Marc Goodner; Corinna Witt; ws-sx@lists.oasis-open.org
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.
> 
> 
> 
_______________________________________________________________________
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]