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] | [Elist Home]


Subject: Re: [wss] RE: [security-services] Canonicalization


Phil,

Just to be sure I understand you. I take the "it" in "can it work in any 
other way?" to
be how the integrity of a SAML assertion is established (and verified to 
support the
claims in the assertion).

It sounds like you are saying that affective use of SAML requires more 
robust
canonicalization be used for signatures in SAML assertions, and thus perhaps
the "it" that can't work (as in be used by ws-security) is the SAML spec.

It seems appropriate for the WSS binding of SAML to call for appropriate
canonicalization of signatures in SAML assertions. It also seems that
the SS TC must adopt (if it hasn't already) a requirement that SAML
authorities must support canonicalization that cannot be subverted by
context replacement

Ron

Hallam-Baker, Phillip wrote:

>Ron,
>
>	I would flip the question arround, can it work in any other 
>way? The problem with the original C14N spec is that is simply does
>not work if you detach nodes and splice them into another context.
>It is arguable that it does not work in any context - we managed
>to get into interop problems on XKMS because of scope issues.
>
>	I don't think we should mandate Exclusive C14N but we should 
>observe that the spec won't work unless the C14N used has the
>detachability property of C14N.
>
>	So while I don't think we should mandate Exclusive we can and 
>should mandate NOT original since in the SOAP context it is broke.
>
>	We knew this was a problem in SAML at the time but exclusive 
>was not a standard so we could not normatively reference.
>
>		Phill
>
>  
>
>>-----Original Message-----
>>From: ronald monzillo [mailto:ronald.monzillo@sun.com]
>>Sent: Tuesday, October 15, 2002 1:00 PM
>>To: Anthony Nadalin
>>Cc: wss@lists.oasis-open.org; security-services@lists.oasis-open.org
>>Subject: Re: [wss] RE: [security-services] Canonicalization
>>
>>
>>Preteek has already pointed out that the SAML token binding
>>defers to the Core for the canonicalization of signatures used for 
>>subject confirmation.
>>
>>The WSS SAML token binding does not impose any requirments on the
>>canonicalization algorithm used for a signature enveloped 
>>within a SAML 
>>assertion.
>>
>>The binding currently does not require that SAML assertions be signed.
>>
>>Prateek has asked in  his note of 10/4  "Comments on  SAML-WSS-02" if 
>>the binding should make it
>>mandatory to implement for recipients to be able to validate 
>>signatures 
>>within SAML assertions.
>>
>>Is it necessary (or even feasible) for WS-security to impose any 
>>requirements on
>>the canonicalization used for signatures within SAML assertions?
>>
>>Anthony Nadalin wrote:
>>
>>    
>>
>>>Agree, we should require SAML Token Binding to support Exclusive
>>>Canonicalization.
>>>Ron is there a reason why  SAML Token Binding is not 
>>>      
>>>
>>consistent with the
>>    
>>
>>>WS-Core ?
>>>
>>>
>>>Anthony Nadalin | work 512.436.9568 | cell 512.289.4122
>>>
>>>
>>>|---------+----------------------------->
>>>|         |           "Ahmed, Zahid"    |
>>>|         |           <zahid.ahmed@comme|
>>>|         |           rceone.com>       |
>>>|         |                             |
>>>|         |           10/15/2002 01:59  |
>>>|         |           AM                |
>>>|---------+----------------------------->
>>> 
>>>-------------------------------------------------------------
>>>      
>>>
>>--------------------------------------------------------------
>>-------------------|
>>    
>>
>>> |                                                          
>>>      
>>>
>>                                                              
>>                      |
>>    
>>
>>> |       To:       wss@lists.oasis-open.org, 
>>>      
>>>
>>security-services@lists.oasis-open.org                        
>>                                     |
>>    
>>
>>> |       cc:                                                
>>>      
>>>
>>                                                              
>>                      |
>>    
>>
>>> |       Subject:  [wss] RE: [security-services] 
>>>      
>>>
>>Canonicalization                                              
>>                                 |
>>    
>>
>>> |                                                          
>>>      
>>>
>>                                                              
>>                      |
>>    
>>
>>> |                                                          
>>>      
>>>
>>                                                              
>>                      |
>>    
>>
>>> 
>>>-------------------------------------------------------------
>>>      
>>>
>>--------------------------------------------------------------
>>-------------------|
>>    
>>
>>>
>>> 
>>>
>>>      
>>>
>>>>I assert that we should have just one version of the required
>>>>Canonicalization specification for WSS and that all the parts
>>>>of the WSS specification require one Canonicalization method.
>>>>I propose that the SAML Token Binding specification and 
>>>>        
>>>>
>>other included
>>    
>>
>>>>specifications into the WSS spec. require the Exclusive 
>>>>        
>>>>
>>Canonicalization
>>    
>>
>>>>spec. where Canonicalization is required.  As precedence, 
>>>>        
>>>>
>>the WSS spec
>>    
>>
>>>>refers to the dsig spec but changes the required 
>>>>        
>>>>
>>canonicalization from
>>    
>>
>>>>that which is required in the dsig spec.  By the same logic, we
>>>>   
>>>>
>>>>        
>>>>
>>>could/should
>>> 
>>>
>>>      
>>>
>>>>do the same for SAML Token Binding.  On the other hand this 
>>>>        
>>>>
>>could cause
>>    
>>
>>>>some consternation with existing implementations of the 
>>>>        
>>>>
>>SAML spec. that
>>    
>>
>>>>just want to use their SAML implementations as is in their WSS
>>>>implementation.
>>>>   
>>>>
>>>>        
>>>>
>>>Having one canonicalization method for WSS Core and SAML Binding
>>>Profile will simplify processing complexity for WSS/SAML
>>>implementations.
>>>
>>>
>>>I believe exclusive canonicalization algorithm requires namespaces
>>>which are (only) declared in an ancestor but used in the document
>>>subset must be propagated _to the first occurence_ of the use of
>>>the namespace, not to the apex node as ordinary canonicalization
>>>would require. Furthermore for exclusive canonicalization, namespaces
>>>which are declared in an ancestor but not used in the document subset
>>>must _not_ be propagated.
>>>
>>>
>>>In support for WS-Security and SAML Binding, a problem that we
>>>experienced is that in addition to propagating namespace 
>>>      
>>>
>>declarations,
>>    
>>
>>>for example as part of de-serializing SOAP message on receiving
>>>side, you may need to propagate attributes from xml: namespace -
>>>which has 2 different processing requirements depending on the
>>>canonicalization algorithm:
>>>
>>>
>>>1)You MUST propagate xml: attributes (such as xml:lang, xml:space
>>>and xml:base) for regular c14n or they must be propagated into the
>>>subset
>>>
>>>
>>>2)You MUST NOT propagatge xml: attributes (such as xml:lang,
>>>xml:space and xml:base)for exclusive c14n into the subset
>>>
>>>
>>>Since most SOAP processing systems at unmarshalling time are
>>>unaware of canonicalization algorithm, we also prefer that SAML
>>>Token Binding require Exclusive canonicalization algorithm to
>>>remain consistent with WSS Core. This will simplify the
>>>processing complexity of propagating attributes from xml: namespace.
>>>
>>>
>>>As Don is hinting it's an either-or situation.
>>>
>>>
>>>I understand that this may have some backward compatibility
>>>issue w.r.t. SAML 1.0 implementations.
>>>
>>>
>>>thanks,
>>>Zahid
>>>
>>>
>>>-----Original Message-----
>>>From: Flinn, Don [mailto:Don.Flinn@quadrasis.com]
>>>Sent: Monday, October 14, 2002 8:35 PM
>>>To: wss@lists.oasis-open.org; security-services@lists.oasis-open.org
>>>Subject: [security-services] Canonicalization
>>>
>>>
>>>
>>>
>>>
>>>The WSS Core specification and the WSS SAML specification 
>>>      
>>>
>>point at two
>>    
>>
>>>different Canonicalization
>>>specifications.  The WSS core uses the latest Canonicalization spec.,
>>>Exclusive XML Canonicalization, at the URL
>>>http://www.w3.org/TR/xml-exc-c14n/ , while the SAML core 
>>>      
>>>
>>specification,
>>    
>>
>>>which is the basis for the WSS SAML Token Binding 
>>>      
>>>
>>specification, uses the
>>    
>>
>>>base Canonicalization, i.e. non-exclusive Canonicalization 
>>>      
>>>
>>spec., at URL
>>    
>>
>>>http://www.w3.org/TR/2001/REC-xml-c14n-20010315 .  The main 
>>>      
>>>
>>difference is
>>    
>>
>>>that the Exclusive XML Canonicalization spec. handles the 
>>>      
>>>
>>situation where a
>>    
>>
>>>child element may be moved and used independent of its 
>>>      
>>>
>>parent and thus may
>>    
>>
>>>have to add the namespaces that were part of the parent 
>>>      
>>>
>>element, whereas
>>    
>>
>>>the non-Exclusive spec doesn't handle this situation.  This 
>>>      
>>>
>>may result in a
>>    
>>
>>>verification failure of the signature when using the non-exclusive
>>>Canonicalization.  The problem arises because the dsig spec was
>>>
>>>
>>>
>>>
>>>
>>>One could make an argument that SAML doesn't allow for 
>>>      
>>>
>>separation of its
>>    
>>
>>>elements.  It's all of SAML or nothing.   I assert that we 
>>>      
>>>
>>should have just
>>    
>>
>>>one version of the required Canonicalization specification 
>>>      
>>>
>>for WSS and that
>>    
>>
>>>all the parts of the WSS specification require one 
>>>      
>>>
>>Canonicalization method.
>>    
>>
>>>I propose that the SAML Token Binding specification and 
>>>      
>>>
>>other included
>>    
>>
>>>specifications into the WSS spec. require the Exclusive 
>>>      
>>>
>>Canonicalization
>>    
>>
>>>spec. where Canonicalization is required.  As precedence, 
>>>      
>>>
>>the WSS spec
>>    
>>
>>>refers to the dsig spec but changes the required 
>>>      
>>>
>>canonicalization from that
>>    
>>
>>>which is required in the dsig spec.  By the same logic, we 
>>>      
>>>
>>could/should do
>>    
>>
>>>the same for SAML Token Binding.  On the other hand this 
>>>      
>>>
>>could cause some
>>    
>>
>>>consternation with existing implementations of the SAML 
>>>      
>>>
>>spec. that just
>>    
>>
>>>want to use their SAML implementations as is in their WSS 
>>>      
>>>
>>implementation.
>>    
>>
>>>
>>>
>>>
>>>Don
>>>
>>>
>>>
>>>
>>>
>>>----------------------------------------------------------------
>>>To subscribe or unsubscribe from this elist use the subscription
>>>manager: <http://lists.oasis-open.org/ob/adm.pl>
>>>
>>>
>>>
>>>
>>>----------------------------------------------------------------
>>>To subscribe or unsubscribe from this elist use the subscription
>>>manager: <http://lists.oasis-open.org/ob/adm.pl>
>>> 
>>>
>>>      
>>>
>>
>>----------------------------------------------------------------
>>To subscribe or unsubscribe from this elist use the subscription
>>manager: <http://lists.oasis-open.org/ob/adm.pl>
>>
>>    
>>




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


Powered by eList eXpress LLC