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

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

Received on Wednesday, 19 September 2007 04:42:12 UTC