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

Yes, I am stating that the final case is NOT a reference validation as you
claim.  It would break because Transform(1) is a signed part of SignedInfo,
so changing to Transform(2) will break the SignatureValue even though the
DigestValue validates.

If you do not sign the ObjectReference transforms, then as I have explained
before, you have the following situation:

Suppose I have a document ABCDE, and I have a transform that says keep all
nodes, except *omit* C, if the transforms are not signed, then an attacker
can change the transform to say *keep* ABDE without breaking the signature.
The difference between the former exclusive logic and the latter inclusive
logic is in what can happen to the document containing AB?DE.  With
inclusive logic, it can become 'aaabbbcccdddAByyyzzzsssssDEblahblahblah'
without breaking the signature.  With exclusive logic, it can only be ABDE
or ABCDE.

As an example, suppose ABDE is the state of the document after a first
signature is added, and C is the work that must be done by a second signer,
then an XPath for the first signer can precisely define C such that it does
not substantially impact the meaning of ABDE.  The XFDL example I gave at
FTF#2 is an example of exploiting this idea, and this is the essence of what
I've been calling document closure.  C represents the body of things that
the can be done to 'close' or finish the document after it has been signed
by signer 1.  Deviation from C breaks the signature.  Thus, the Xpath
transform that says 'Omit C' is a signed assertion that the signature of
signer 1 is valid if and only if changes other than C have not been made to
the document.

John Boyer
Software Development Manager
UWI.Com -- The Internet Forms Company


-----Original Message-----
From: Joseph M. Reagle Jr. [mailto:reagle@w3.org]
Sent: Wednesday, November 24, 1999 12:10 PM
To: John Boyer
Cc: Donald E. Eastlake 3rd; Dave Solo; DSig Group; Tim Berners-Lee
Subject: 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:44:34 UTC