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: 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>
>  
>




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


Powered by eList eXpress LLC