RE: Simplified Syntax (The Crux of the Matter!)

At 17:03 99/11/23 -0800, John Boyer wrote:
 >In other words, if an attacker were to modify the document in a way that is
 >not permitted by the (signed) XPath transform in the ObjectReference, then
 >the signature would still break because the wrong message would be
 >constructed for comparison to the DigestValue.
 >
 >So, the XPath can indeed protect the entire document from unwanted
 >modifications despite the fact that it drops out certain pieces.  When we
 >verify, start with a document, and apply the XPath transform.  If the
 >signature validates, then two assertions can be made: 1) the document
 >contains all the bits it used to contain, PLUS 2) the document as a whole
 >has not been modified in ways contrary to the precise definitions given in
 >the XPath.  This is the essence of how XFDL signatures work, only there was
 >no XPath at the time, so we created our own syntax (it is specific to XFDL
 >parse trees, whereas we now require XPath because we want to do the same
 >idea only on generic XML documents).
 
Consider 4 cases:

Document(A)  --Transform(1)-->  DigestContent(A)  --Digest -->  DigestValue(A)
        where Document(A) when transformed results in a 
        DigestValue(A).
Document(A')  --Transform(1)-->  DigestContent(A)  --Digest -->  DigestValue(A)
        where Document(A') includes changes to the material 
        excluded by Transform(1). (reference validation)
Document(B)  --Transform(1)-->  DigestContent(B)  --Digest -->  DigestValue(B)
        where Document(B) includes changes from Document(A)
        that were part of the included portion, resulting in a different
        DigestValue. (reference invalidation)
Document(C)  --Transform(2)-->  DigestContent(A)  --Digest -->  DigestValue(A)
        where Document(C)<>Document(A) and Transform(2)<>Transform(1)
        I believe I am stating that the later case is a true reference validation.
        I believe you are asserting it is not.

Consider a more concrete instances of examples 1 and 4.

Document(A)
   <ordered>
        <name>joe</name>
        <name>john</name>
        <name>david</name>
   </ordered>
Transform(1)
        select second name element (then digest and sign)

Document(B)
   <ordered>
        <name>john</name>
        <name>joe</name>
        <name>david</name>
   </ordered>
Transform(2)
        select first name element (then digest and sign)

I'm saying the DigestValues of both things will be equal, and if the signature was over the first, then it will validate the second. You are saying they should not be, and I don't understand why (aside from the wrong side of the stick) since the thing you signed was the digest of "<name>john</name>" in either case!

If one were to argue that the user will be shown Document(A,B) not DigestContent(A,B) and these elements were ordered (who sent the most email <smile>), then I could sort of see your argument. However, Tim's point was that you are signing the derived content, and if these things are ordered and you want to preserve that ordering, then your transform should have captured that bit of syntax!! You still get closure.

_________________________________________________________
Joseph Reagle Jr.   
Policy Analyst           mailto:reagle@w3.org
XML-Signature Co-Chair   http://www.w3.org/People/Reagle/

Received on Wednesday, 24 November 1999 15:09:49 UTC