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

Dear all,

I was pointed to the Draft by Meiko Jensen and was looking deeply at "4.4.3..9 The dsig2:Verification element" in the Working Draft <http://www.w3.org/TR/xmldsig-core2>.

There is a point about the Verification element <dsig2:IDAttributes> that I either do not fully understand or that worries me:

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. 
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>?

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

Let me explain why I asked myself this … I understand that having IDbased selection in the <reference> the signer might make the *implicit* assumption that the attribute the signer used as a selection criteria is a unique ID … he can now *explicitly* state this with <dsig2:IDAttributes>. 
But I can only think of an attack where an attacker creates two elements with the same ID that was used for referencing and we all have seen "trouble" in the wild due to "parsing issues".
However, assume a verifier receives a signed XML, which has multiple elements under the same "id", and that "id" is used for selection in the dsig <reference>. We we have multiple options of what could happen:
1) the verifier's parser selects all this duplicate elements and starts digesting them
2) the verifier's parser selects only a some of the duplicates (i.e. the first occurrence, the last occurrence, …) and starts digesting *only* this subset
3) the verifier's parser selects none of the duplicates and digests the empty string
An attack can not happen in the case of #1 or #3, as far as I am concerned, as this will result in mismatching digest-values.
So the only interesting case is #2 and this is only interesting if we further assume a *mismatch* between the verifier's parser and the application's parser, nevertheless this is where we see attacks happening in the wild.

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.

By the way, I really like the idea of the other two suggested values:
<dsig2:DigestDataLength>: Makes a lot of sense to me, because this will help debugging/visualize what the signing process got as an input. If this is used a lot it will not only help the verifier to understand what was signed, but mostly help the signer to detect errors (either in their selection criteria or the data submitted for signing).

<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.

I do have another question regarding the ByteRange but I take this into another post.

Best Regards,
Henrich C. Pöhls


-- 
This email is:       [ ] private     [ ] ask before forwarding    [X] public

Dipl.-Inform. M.Sc. Info.-Security Henrich C. Poehls
Research Assistant
Institute of IT-Security and Security Law (ISL)
University of Passau, Innstr. 43, 94032 Passau, Germany
Room: 136
Tel: +49 851 - 509 3217
<http://web.sec.uni-passau.de/members/henrich>

Received on Friday, 5 November 2010 13:06:14 UTC