Re: Action-350 ( was RE: Issue 4951 -- Reformulation

Ashok,

Basically, I completely agree with Asir's response. SOAP has no concept of 
ordering of the
SOAP header blocks. However, the SOAP1.2 spec does suggest that it would 
be possible
for someone to devise such a SOAP header. Thus, ordering is not part of 
the SOAP processing model,
but the SOAP processing model provides the framework in which such ordered 
behavior might be
affected, by virtue of a SOAP header that carried the semantic of 
indicating the order of 
processing of the behaviors represented by the SOAP headers.

Policy is no different in this regard. As has been demonstrated with the 
WS-Security Policy
example that Asir cites, an assertion may indeed affect the order of 
processing of the
behaviors. Note that it is the behaviors that are affected, not the order 
in which the 
assertions that indicate such behaviors are included in the policy 
alternative.

As I indicated in the previous call, when you were present, it isn't the 
assertions, it is the
specifications of those behaviors that specify their relationship to other 
behaviors. If another
behavior comes along after-the-fact, then profiles, such as the WS-I 
profiles can be
written such that they clarify the order of processing of the behaviors.

Bottom line, this isn't a framework concern, IMO.

Cheers,

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
phone: +1 508 234 2986

public-ws-policy-request@w3.org wrote on 09/19/2007 12:42:00 AM:

> 
> Hello Ashok,
> 
> I spoke with our security and reliable messaging experts.
> 
> > The issue has to do with ordering between assertions.
> > The spec says that users can write special assertions that
> > control the ordering between assertions.  Examples are the
> > "sign before encrypt" and "encrypt before signing" assertions
> > in WS-Security Policy.
> 
> The order of assertions in a policy alternative has no bearing on 
> the order of cryptographic operations. WS-SecurityPolicy provides 
> assertions to control the order of cryptographic operations (runtime
> behavior) on a message. In fact, the WS-SecurityPolicy Section 5 
> says, 'when assertions defined in this section are present in a 
> policy, the order of those assertions in that policy has no effect 
> on the order of signature and encryption operations' [1].
> 
> > But the interesting issues come up when ordering is
> > desired between assertions from different domains, for
> > example adding RM headers and encrypting the headers.
> 
> The interrelation between the RM headers and security can be 
> expressed using the protection assertions [1][2] in WS-
> SecurityPolicy. The EncryptedParts assertion can be used to specify 
> that an RM Sequence header requires confidentiality. For instance,
> 
> <sp:EncryptedParts>
>   <sp:Header Name="Sequence"
>      Namespace=" http://docs.oasis-open.org/ws-rx/wsrm/200702"/>
> </sp:EncryptedParts >
> 
> In this context, applying the 'sign before encrypt' or 'encrypt 
> before signing' is business as usual.
> 
> According to the SOAP messaging framework [4], in general, the order
> of headers and body processing is at the discretion of the SOAP node
> and SOAP headers may be used to control the order of processing. 
> This is the reason why there are NO real scenarios (just as you 
> confirmed this on the WG conference call last week) where expressing
> the order of SOAP headers and body processing outside a SOAP message
> would be useful.
> 
> We hope this mail answers your 4951 related questions, closes action
> 350 [5] and resolves issue 4951 [6].
> 
> [1] http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-
> securitypolicy-1.2-spec-os.html#_Toc161826510
> [2] http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-
> securitypolicy-1.2-spec-os.html#_Toc161826512
> [3] http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-
> securitypolicy-1.2-spec-os.html#_Toc161826515
> [4] http://www.w3.org/TR/2003/REC-soap12-part1-20030624/#procsoapmsgs
> [5] http://www.w3.org/2005/06/tracker/wspolicy/actions/350
> [6] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4951
> 
> Regards,
> 
> Asir S Vedamuthu
> Microsoft Corporation
> 
> 
> -----Original Message-----
> From: public-ws-policy-request@w3.org [mailto:public-ws-policy-
> request@w3.org] On Behalf Of ashok malhotra
> Sent: Wednesday, September 12, 2007 11:55 AM
> To: public-ws-policy@w3.org
> Subject: Issue 4951 -- Reformulation
> 
> 
> Here is a reformulation of issue 4951 based on discussion on morning's
> telcon.  Thanks to Paul Cotton for contributing to this.
> 
> The issue has to do with ordering between assertions.  The spec says
> that users can write special assertions that control the ordering
> between assertions.  Examples are the "sign before encrypt" and "encrypt
> before signing" assertions in WS-Security Policy.  But the interesting
> issues come up when ordering is desired between assertions from
> different domains, for example adding RM headers and encrypting the
> headers.  In such cases, which namespace does the ordering assertion go?
> 
> The other response to this issue is that the semantics of each assertion
> includes the ordering information.  I think this is  problematic.
> 
> Consider a universe of assertions U  that includes assertions A1, A2,
> ... An.  Assume  further that  the semantics of each assertion Am
> indicates its ordering wrt all other assertions in U ... or at least the
> assertions where ordering matters.  Now, we add another assertion X into
> the universe U.  Not only do we need to specify the order of X wrt all
> the assertions in U, we have to change the semantics of all the existing
> assertions in U to specify the order wrt X.  This seems to be a problem
> to me.
> --
> All the best, Ashok
> 
>