- From: Pratik Datta <pratik.datta@oracle.com>
- Date: Sat, 16 Oct 2010 15:37:10 -0700 (PDT)
- To: Scott Cantor <cantor.2@osu.edu>, public-xmlsec@w3.org
This is associated with ACTION-647 and ACTION-661 Scott, the action tracker scans the message body for actions and associates relevant emails with the action. In your reply you had removed the ACTION-647, so I am adding that back in. Pratik -----Original Message----- From: Scott Cantor [mailto:cantor.2@osu.edu] Sent: Monday, October 11, 2010 6:57 AM To: Pratik Datta; public-xmlsec@w3.org Subject: RE: ACTION-581: proposal around IDness of attributes > As Scott mentioned, even with XPath 1.0, it is possible to make it work with > ID attributes beyond DTD by using the DOM 3 functions to mark ID attributes. And schemas. It seems pretty weird to me that the W3C would produce yet more specs that ignore IDness from XML Schema unless that's a deliberate architectural choice to once and for all say that schema IDs are not the same as DTD IDs (which has been an ongoing argument for years). (That's more of a comment about XPath 2 than us, since I think XPath 2 came after XSD, right?) > My opinion is that we should not use the dsig2:IDAttributes function to > defined ID attributes for XPath profile. Because > a) First of all we don't even need id() functions in XPath for dsig. We > already have the URI mechanism in dsig which is widely used, we have already > agreed to allow URI references to uses ids defined by the > dsig2:IDattributes. However we are telling users to avoid using IDs because > of the possibility of wrapping attacks, instead they should use XPaths. > Obviously they should not use the id() function in attributes, because it > comes back to the whole issue of wrapping attacks. Well, let me just say that there *are* ways around those attacks if you have application specific knowledge in your verifier. Not every implementation is trying to be an appliance that can process signatures with no regard for what's being signed. > b) Secondly , one of the major DOM parsers used inside Oracle is not fully > DOM3 compliant, and it does not support the setIDattribute function. There > may be other DOM parsers in the similar situation too. So this may not be > easy to implement for all parsers. That doesn't create false positives though, only false negatives. That isn't a security risk, and those of us who use IDs extensively have many reasons to avoid such parsers anyway. > I say that we leave the id() function exactly as it is in XPath 1.0, i.e > defined by DTD only. I would argue for consistency across all uses of IDness in the spec, or alternatively that id() just be pulled from the XPath subset if you don't want to use it. -- Scott
Received on Saturday, 16 October 2010 22:38:11 UTC