W3C home > Mailing lists > Public > public-xmlsec@w3.org > November 2010

RE: XML Sig 2.0: What protection is gained by the <dsig2:IDAttributes> element?

From: Scott Cantor <cantor.2@osu.edu>
Date: Fri, 5 Nov 2010 09:49:27 -0400
To: "'Poehls, Henrich'" <hp@sec.uni-passau.de>, <public-xmlsec@w3.org>
Message-ID: <000301cb7cf0$44c53040$ce4f90c0$@osu.edu>
> As far as I understood the <dsig2:IDAttributes> captures the signer's
> semantic view of certain XML parts in respect to the IDness-properties
(i.e.
> uniqueness) of the attributes listed herein.

IDness is about more than just uniqueness, it's also about how DOM elements
can be accessed and located in a tree.

> Thus the signer wants to tell the verifier how he wants the listed
attributes to
> be understood. Please, correct me if I am wrong here.
> A provoking question: Why is this semantic more important than other
> semantics, for instance the "<billing-adress>" is supposed to exist only
once
> in an <order>?

Because ID attributes are used in Reference syntax via fragments ("#foo")
and the ability to identify attributes that are IDs affects the ability to
properly dereference and compute the digest. This is a long standing problem
across older XML specs that support XML Signature, as anybody that has
supported SAML can attest. It has nothing to do with the semantics of the
data relative to the document's "meaning" or domain of use. It's simply the
fact that xml:id came far too late to matter.

> A more security minded question: What attack/threat is
<dsig2:IDAttributes>
> protecting against?

It doesn't. The inability to identify an ID causes false negatives, which
are a denial of service of a sort, but not generally thought of as a
security risk. It's a usability issue with the technology because there were
no standard ways to identify IDs outside of DTD and schema use before xml:id
existed.

> So I would suggest that: For IDbased selection the verifier always has to
> perform if the attribute given in selection is unique as this could be the
> default assumption why the signer chose it for selection? Thus, you can
> simply omit the <dsig2:IDAttributes> completely.

Nobody goes searching through an entire tree for a particular attribute
value (and if you did, the value doesn't have to be unique within the entire
document, only across all *IDs* in the document). The point of identifying
ID attributes is to support the use of the DOM API for accessing an element
by ID.

If you're suggesting that there are attacks possible, I can't really
disagree with that, but providing information about ID attributes doesn't
increase that risk, and it does allow for more success in verifying correct
signatures. That's the motivation.

> <dsig2:PositionAssertion>: I see this as an additional clue that the
position of
> the data was important to the signer.
> IMHO the signer should make this *explicit* (as this is only optional) by
using
> a selection statement that incorporates the position i.e. XPath, instead
of
> using an ID-based selection.

Not every situation allows for XPath, and SAML among many other specs relies
exclusively on ID-based references because the thing being signed is a unit,
can be moved around, and its position in the document as a whole is an issue
for higher-level standards.

-- Scott
Received on Friday, 5 November 2010 13:50:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 5 November 2010 13:50:08 GMT