Title: 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:]
Sent: Monday, October 14, 2002 8:35 PM
To: ;
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>
