RE: ACTION-581: proposal around IDness of attributes

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