[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wss] RE: [security-services] Canonicalization
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC