W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > January to March 2005

Re: Test Case with xml-dsig

From: Rich Salz <rsalz@datapower.com>
Date: Tue, 08 Feb 2005 12:47:42 -0500
Message-ID: <4208FB3E.4040401@datapower.com>
To: John Boyer <JBoyer@PureEdge.com>
CC: Elliotte Harold <elharo@metalab.unc.edu>, Norman Walsh <Norman.Walsh@Sun.COM>, Joseph Reagle <reagle@mit.edu>, Gabe Wachob <gwachob@wachob.com>, public-xml-id@w3.org, w3c-ietf-xmldsig@w3.org

(The To/CC list is getting long, and I didn't want to inadvertently 
remove anyone.  Sorry if you get multiple copies.)

I think there's enough bugs for everyone to share. :)

First, let's make explicit that it's not just C14N but EXC-C14N.  The 
latter is the prefered way mechanism to use for securing web services 

As I understand it, the core problem is that C14N/EXC-C14N say that 
xml:XXX are to be imported into the document if not explicilty included 
in the part being signed.  This means we have a straightforward, 
although technically subtle, work-around: do not use xml:id on any outer 
elements of signed content.  Of course, since you might not have any 
control over outer elments, this is probably not practical.  I think 
it's a big deal that you can take any signed document, put it inside
    <f xml:id="x">....<f>
and any signature will now fail to validate.  (Replace <f> with a SOAP 
envelope, for example.)

This is a bummer.

C14N/EXC-C14N talk about special handling of attributes in the "xml" 
namespace.  This is arguably a bug, since it assumed that all other 
attributes in the namespace would have similar semantics.  If the spec 
explicitly called out the attributes to get this special treatment, we 
wouldn't have a problem.  Since it didn't, it implicitly assumed that 
all XML attributes would scope.  Oh well.

On the other hand, it's arguably a bug that there is a new attribute in 
the XML namespace because it breaks existing software, and because its 
semantics are fundamentally different from most others.

I haven't bothered to research when xml:base entered the timeline.

It is amazingly ironic that many people in the XML Security community 
(e.g. WS-Security, the SAML committee, etc) were looking forward to 
xml:id as a global way to define an ID attribute, so that each standard 
can begin to phase out their own specific attribute.  And now, that very 
community runs the risk of signatures failing to validate.

What are the next steps?  I can think of two.  The WS-I profile folks 
should be notified (I'll do that), and the TAG should re-examine the issue.

Make sense?


Rich Salz, Chief Security Architect
DataPower Technology                           http://www.datapower.com
XS40 XML Security Gateway   http://www.datapower.com/products/xs40.html
XML Security Overview  http://www.datapower.com/xmldev/xmlsecurity.html
Received on Tuesday, 8 February 2005 17:46:52 UTC

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