W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > April to June 2006

Re: XPath Transforms Deprecated in SAML 2.0

From: Michael McIntosh <mikemci@us.ibm.com>
Date: Sat, 29 Apr 2006 08:54:56 -0400
To: "Anders Rundgren" <anders.rundgren@telia.com>
Cc: w3c-ietf-xmldsig@w3.org, w3c-ietf-xmldsig-request@w3.org
Message-ID: <OF688EE7D0.E3C86F8C-ON8525715F.00450744-8525715F.0046F064@us.ibm.com>

w3c-ietf-xmldsig-request@w3.org wrote on 04/28/2006 04:43:25 PM:

> http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf
> 
> Reading this relatively recent document I get the impression that 
> the XPath stuff that once were developed for use with XML 
> Signatures, caused problems.

I am not sure I understand. I don't see XPath mentioned there at all. I 
assume you are referring to the statement:

"Verifiers of signatures MAY reject signatures that contain other 
transform algorithms as invalid. If they do not, verifiers MUST ensure 
that no content of the SAML message is excluded from the signature. This 
can be accomplished by establishing out-of-band agreement as to what 
transforms are acceptable, or by applying the transforms manually to the 
content and reverifying the result as consisting of the same SAML 
message."

Are you looking to deprecate XPath as a transform algorithm? 

> The document says that enveloped-signature and exclusive 
> canonicalization are the only Transform elements that a receiver 
> MUST recognize.
> 
> Although I prefer XPath as you can get away from ID tags and not 
> have to worry about collisions, I guess that for a new standards 
> effort, it would be foolish not to build on the experiences with SAML.

I think SAML's requirements for signatures over assertions and messages - 
while typical of many scenarios - do not cover all of the important 
scenarios for XML Signatures. The SAML protocol does not allow any 
transformation of an assertion or message between its generation and its 
consumption. Other protocols (e.g. SOAP, workflows, etc.) require 
allowance for these intermediate transformations of explicitly selected 
subsets. We should also take these scenarios into account.

> I have one question though: Can anybody explain what InclusuveAttributes
> does and what happens if it is not specified?  What prefixes should 
> be specified?  Those that are a part of the signed message?

I don't know the term InclusiveAttributes, do you mean 
InclusiveNamespaces? If so, Section 3 of 
http://www.w3.org/TR/xml-exc-c14n/ explains the processing in some detail 
and Section 9.5 of 
http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html makes an 
attempt at interpreting what is expected to be placed into the PrefixList.

> Anders Rundgren
> 
> 

Thanks,
Michael McIntosh
Received on Saturday, 29 April 2006 12:55:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:40 UTC