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

Hi Tim,

-----Original Message-----
From: Tim Berners-Lee [mailto:timbl@w3.org]
Sent: Sunday, November 28, 1999 1:53 PM
To: John Boyer; Joseph M. Reagle Jr.
Cc: Donald E. Eastlake 3rd; Dave Solo; DSig Group
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.

<John>
Incorrect.  What is covered by the digest is ABDE, but within ABDE is a
*signed* assertion that the only allowable difference between the document
and ABDE is the addition of C between B and D.  Can you please state why you
think this is insecure?  I don't think you can.
</John>

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

<John>
Again, the digest covers ABDE, but ABDE includes an assertion that the only
allowable difference between the document and ABDE is the possible addition
of a *specific* C (not any C).
I don't understand why this is so hard to understand.
</John>

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

<John>
Not complicated at all, been doing it for years!
</John>

Could we just have a way of signing an XML
document?

<John>
We do, and the XPath transforms in that specification, *recommended by the
W3C*, provides a precision syntax for the representation of the concept I
have been trying for months and months to get people to understand.
</John>

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

<John>
Right.  On this I have very clearly built the assertion that ABDE contains a
very precisely defined (using XPath) assertion about what can happen to the
document without breaking the signature on ABDE. It is a pain to keep
repeating this, but every time someone sends a letter of disagreement
without considering the viability of this idea, document closure, what
choice have I but to respond (over and over and over and over again)?

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

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 Wednesday, 1 December 1999 11:51:17 UTC