RE: XPath Transforms Deprecated in SAML 2.0

 
The  XPath v1.0 transform has advantages and disadvantages. The
advantages are that 

*	
	It is supported by many toolkits and that 
*	
	You can select arbitrary complex nodesets with it. 

The disadvantages (from my personal point of view) outweight the
advantages: 

*	
	You can select arbitrary complex nodesets with it: It's very
easy to shoot yourselves into the foot with XPath v1. People construct
XPath transforms and think they sign what they intended to sign, but
they actually sign an empty or constant node set, and they don't cover
the nodes they actually wanted to protect. Just look at the dsig spec
and see how the XPath transform looks like that is equivalent to the
enveloped-signature transform. Walk through it step by step, and if you
feel that it is NOT easy to understand, then welcome to the club. 
*	
	Performance is REALLY bad, especially compared to XPAth filter
v2, because the XPath expression has to be evaulated against *every*
node in the input node set. 

If you want to see why XPath v1.0 is so complicated, look at Merlin
Huges Y4 test vectors and check out what nodes are REALLY signed, i.e.,
covered by the digest method. I generated traces for these (what I like
to call 'esotiric node sets') here: 
 
http://cvs.apache.org/viewcvs.cgi/xml/security/trunk/data/interop/c14n/Y
4/
 
Each .html contains a highlighted view on the original document with the
nodes that go into the digest method, the .txt files contain the real
octets that go into the hash. Many of the things are not even XML any
longer...
 
 
So when recommending in a signature profile to NOT use XPath1 but only
URI="#ID1", enveloped signature,  and exclC14n, that's a safe bet on
getting a robust system. The only disadvantage is that URI="#FOO" needs
to be resolved, thus requiring DTD, Schema, or custom ID resolving. But
that's better than having an insecure product. 
 
Very best regards,
Christian 
 
--------------

Dr.-Ing. Christian Geuer-Pollmann
European Microsoft Innovation Center (EMIC)
Ritterstrasse 23
52072 Aachen, Germany
 
web:    http://www.emic.eu/
web:    http://blogs.msdn.com/chgeuer/


________________________________

From: w3c-ietf-xmldsig-request@w3.org
[mailto:w3c-ietf-xmldsig-request@w3.org] On Behalf Of Anders Rundgren
Sent: Freitag, 28. April 2006 22:43
To: w3c-ietf-xmldsig@w3.org
Subject: XPath Transforms Deprecated in SAML 2.0


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.
 
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 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?
 
Anders Rundgren