RE: Security Considerations - Initial Proposal

May I suggest a slight amendment to this? I'd suggest "an XML digital signature that covers the wsa:EndpointReference" - the location of the signature is not important; what is important is that covers the EPR. For that matter, I'm unsure if the right word is "covers" - perhaps "encompasses" or "includes"?
 
Gotta be pedantic :-)
 
Tony Rogers

	-----Original Message----- 
	From: public-ws-addressing-request@w3.org on behalf of Francisco Curbera 
	Sent: Thu 24-Feb-05 13:53 
	To: Martin Gudgin 
	Cc: Anthony Nadalin; Chris Kaler; public-ws-addressing@w3.org; public-ws-addressing-request@w3.org; Rich Salz 
	Subject: Re: Security Considerations - Initial Proposal
	
	


	We like Gudge's proposal but we think we need to call out explicitly the
	use of XML Digital signatures within an EPR as one of the mechanisms to
	protect its integrity. I am thus proposing this (friendly) amendment to the
	first paragraph of Gudge's proposal:
	
	EPRs SHOULD be integrity protected to prevent tampering. Such optional
	integrity protection can be provided by transport, message level signatures
	or inclusion of an XML Digital Signature within the wsa:EndpointReference
	element.
	
	Paco
	
	
	
	
	                                                                                                                                              
	                      "Martin Gudgin"                                                                                                         
	                      <mgudgin@microsoft.com>         To:       <public-ws-addressing@w3.org>                                                 
	                      Sent by:                        cc:       Anthony Nadalin/Austin/IBM@IBMUS, "Rich Salz" <rsalz@datapower.com>, "Chris   
	                      public-ws-addressing-req         Kaler" <ckaler@microsoft.com>                                                          
	                      uest@w3.org                     Subject:  Security Considerations - Initial Proposal                                    
	                                                                                                                                              
	                                                                                                                                              
	                      02/21/2005 09:53 AM                                                                                                     
	                                                                                                                                              
	
	
	
	
	
	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.