- From: Marc Hadley <Marc.Hadley@Sun.COM>
- Date: Tue, 22 Feb 2005 19:10:18 -0500
- To: Martin Gudgin <mgudgin@microsoft.com>
- Cc: public-ws-addressing@w3.org, Anthony Nadalin <drsecure@us.ibm.com>, Rich Salz <rsalz@datapower.com>, Chris Kaler <ckaler@microsoft.com>
Gudge, Just wondering how this proposal is related to the existing Security Considerations section[1] in the SOAP Binding. It seems to cover much of the same ground. Is it intended as a delta to the existing text or as a replacement ? Thanks, Marc. [1] http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr- soap.html#_Toc77464334 On Feb 21, 2005, at 9:53 AM, Martin Gudgin wrote: > > The following is an initial proposal for text for a security > considerations section for WS-Addressing. We may need to add stuff to > this, but I think this provides a 'minimum bar'. > > Comments welcome, > > Gudge > > ---------------------------- > > Security Considerations > > EPRs SHOULD be integrity protected to prevent tampering. Such integrity > protection can be provided by transport or message level signatures. > > Users of EPRs SHOULD only use EPRs from sources they trust. In practice > this is likely to mean that users of EPRs only use EPRs that are signed > by parties the user of the EPR trusts. > > WS-Addressing headers (wsa:To, wsa:Action et.al.) including those > headers present as a result of processing ReferenceParameters in an EPR > SHOULD be integrity protected. Such integrity protection can be > provided > by transport or message level signatures. > > To prevent information disclosure EPR issuers SHOULD NOT put sensitive > information into wsa:Address values or Reference Parameters. > > > In addition to the above, the following text needs to be in a normative > section of the spec, probably in the SOAP binding somewhere. We really > need to do this otherwise we'll have to define a WS-A normalization > algorithm and I'd much rather not do that... > > To avoid breaking signatures, intermediaries MUST NOT change the XML > representation WS-Addressing headers. Specifically, intermediaries MUST > NOT remove XML content that explicitly indicates otherwise-implied > content, and intermediaries MUST NOT insert XML content to make implied > values explicit. For instance, if a RelationshipType attribute is > present with a value of "http://www.w3.org/@@@@/@@/addressing/reply", > an > intermediary MUST NOT remove it; similarly, if there is no > RelationshipType attribute, an intermediary MUST NOT add one. > > --- Marc Hadley <marc.hadley at sun.com> Web Technologies and Standards, Sun Microsystems.
Received on Wednesday, 23 February 2005 00:10:24 UTC