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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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


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 accepted before the Exclusive Canonicalization spec. was written and thus doesn't reference the Exclusive Canonicalization spec.

 

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



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


Powered by eList eXpress LLC