- From: Rich Salz <rsalz@datapower.com>
- Date: Tue, 08 Feb 2005 12:47:42 -0500
- 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
messages.
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?
/r$
--
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