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

-----Original Message-----
From: John Boyer <jboyer@uwi.com>
To: Joseph M. Reagle Jr. <reagle@w3.org>
Cc: Donald E. Eastlake 3rd <dee3@torque.pothole.com>; Dave Solo
<dsolo@alum.mit.edu>; DSig Group <w3c-ietf-xmldsig@w3.org>; Tim Berners-Lee
<timbl@w3.org>
Date: Wednesday, November 24, 1999 3:44 PM
Subject: 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.

That doesn't matter, because what is signed is ABDE, not the original
document.

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

But neither matters, as it is *not* the *document* which is signed.
The signature is not on "the document ABCDE except with any C". It is on
ABDE.

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


Much too complicated IMHO.  Could we just have a way of signing an XML
document?
If you want tro describe the XML document as the result of a transform of
som,e sort,
fine, but the thing which is being signed must be clear and distinct
and (even though it may not correpond to any resource on the web)
must be a self-defining XML document.  In the above case, ABDE.
On this you can build everything very clearly, without getting involved in
decising for some document semantics what would "substantially impact the
meaning".

Tim
>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 Sunday, 28 November 1999 16:51:48 UTC