- 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