OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wss] SOAP MustUnderstand issue


I wanted to make a few points about the last paragraph, but I'm not sure exactly what the hypothetical WS-I profile would look like and what its goals would be.  For the sake of illustration, let me use DSIG as an example.
 
XML DSIG specifies that XMLC14N and DSA are required for "Core Generation" and "Core Validation" processors.  XML DSIG does not specify any conformance points for other types of processors.
 
Just because a signature is included in a security header does not mean that the security processor must call the DSIG "Core Validation" processor.  The security processor simply needs to understand that what it is looking at is a signature.  Now if the security processor knows that the application doesn't even care who is sending the message (the sole purpose of this security processor is just to decrypt things for the application), then the security processor understands that the signature is a signature and that it is something the application does not need.  Therefor, it does not misunderstand the signature but it also does not waste time calling the DSIG "Core Validation" processor.
 
In a similar fashion, if the security processor has been configured by the application to know that this is a high-risk application and all senders must be authenticated with some #ultraSecure signature algorithm, and if it gets a message with a signature in the security header, it may check the signature description.  If the signature description does not indicate use of the #ultraSecure signature algorithm, the security processor will have understood that the signature is not sufficent and will generate a fault.  This will happen even if the signature in the header indicates use of DSA.  It is certainly not the intention of the dsig spec to require that all security processors accept DSA as valid proof, only that "Core Validation" processors support checking DSA signatures, *should a security processor choose to accept it as valid proof*.
 
So, if WS-I is going to make a profile that requires RSA to supported for WS-Security, we'd need to know exactly what that means and why WS-I is specifying that.
 
If the goal is just to require that RSA infrastructure is available, then that would probably be like the DSIG case.
 
If the goal is to create a class of security processors that will at minimum accept RSA as valid proof, then all security processors that comply to that must accept RSA as valid proof if they require proof.  However, if they don't require proof, then they don't need to validate the signature, as it can be safely ignored.  In any event, if this is the goal, WS-I will have to consider if it is reasonable for them to be trying to set the security practices and policies of its constituents.
 
If the goal is to create a class of security processors that will at minimum accept RSA as valid proof and at minimum require RSA as valid proof, then all conformance security processors would have to require accept and require RSA as valid proof and I think we would be in the situation described in your last paragraph.  However, at this point WS-I has specified the entire security policy of the conformant security processors.  I do not know whether such a specification will be perceived by most as an unwelcome overspecification or a welcome specification of details.  In any event, this is something for WS-I to decide.  Within WS-Security we should remain flexible and stay away from specifying security policy of security processors.
 
&Thomas.

	-----Original Message----- 
	From: Reid, Irving [mailto:irving.reid@hp.com] 
	Sent: Thu 11/6/2003 10:16 AM 
	To: Anthony Nadalin; Rich Salz; wss@lists.oasis-open.org 
	Cc: 
	Subject: RE: [wss] SOAP MustUnderstand issue
	
	

	> From: Anthony Nadalin [mailto:drsecure@us.ibm.com]
	>
	> > proposal: add mustUnderstand to toplevel wsse:Security elements, in
	> addition to wsse:Security
	>
	> Not seeing value in this as these sub-elements have the same
	> mustUnderstand
	> semantics associated with the wsse:Security header by default
	
	I agree. I like Thomas DiMartini's approach in his recent message (http://www.oasis-open.org/archives/wss/200311/msg00019.html), though I'm not sure we need to go into so much detail.
	
	I think the correct way to interpret these mustUnderstand issues is to look at the specific sub-elements of <wsse:Security> and decide which ones are critical to the entire <wsse:Security>.
	
	The reasonable default, in my mind, is "all sub-elements are critical unless the specification says otherwise". This covers the "notAfter" example; if a receiver can't process notAfter, it MUST behave as if it cannot process the entire <wsse:Security>.
	
	At that point the SOAP mU processing kicks in: if the <wsse:Security> was marked mU, the receiver MUST generate a fault. Otherwise, the receiver MAY ignore it. This puts some burden on the sender; if the <wsse:Security> is critical to the processing of the entire SOAP message, then of course the sender should mark it mU.
	
	
	
	I think we should open three new issues:
	
	a) Add text near the top of the spec that says "all sub-elements are critical unless specified otherwise"
	
	b) Go over the spec in detail, and identify exactly which sub-elements MAY ALWAYS be safely ignored without changing the semantics of the <wsse:Security>, and add text for each making that clear. (this may be an empty set)
	
	c) Go over our extension points in detail, and identify any that require a nested mU flag. The semantics of this flag are: if the extension point is mU and you don't understand the extension, you MUST behave as if you don't understand the entire <wsse:Security>. If the extension is not mU, you MAY ignore it and process the rest (or you MAY toss the entire <wsse:Security> anyways). As with the SOAP-level mU flag, the burden is on the sender to correctly flag the extension elements. Also, extension specifications can require that their top-level elements be marked mU if they feel strongly about it.
	
	c.1) if an extension point doesn't support a mU flag, rule a) applies and any extension at that point is critical (but see below)
	
	c.2) As with b), we might decide that all extensions are critical, at which point we don't add any mU flags and everything goes back to rule a).
	
	
	
	Remember that mU processing *DOES NOT* require *every* implementation to support *every* possible variation and extension; the only requirement is that they correctly generate a fault if said variation or extension is not supported. The WS-Security spec and WS-I profiles will guide implementers as to exactly which variations to handle in order to be a "conforming implementation" under the specific profile.
	
	So, for the XMLDsig example, we can treat it as "always critical". If some hypothetical WS-I profile says that you need only support RSA signatures, a conforming (to that profile) implementation MUST process messages that contain <wsse:Security> headers that contain RSA sigs. If they receive a <wsse:Security> that contains a DSA signature, they MUST *either* process it correctly or generate a fault; generating the fault is conformant with the profile, since the (hypothetical) profile does not require DSA support.
	
	To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup.php.
	
	



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]