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

I agree with Tim. What is authenticated by the cryptography is exactly the
bit
stream that is fed into the signature algorithm.

That that bit stream may represent a document ABDE = F(ABCDE, C) is
irrelevant.
The signature makes no statement concerning ABCDE, it is only the bit stream
representing the document that is authenticated.

To ignore the distinction between the bit stream and the document is to fail
to recognize a potential target of attack, the interpretation of the bit
stream as a document.

While I am confident that we can develop a DigSig specification that
protects
against this mode of attack, and indeed it is essential that we do so if
DigSig is to offer more than a PKCS#7 wrapper arround XML, we can only be
confident that we protect against the risk if we recognise it as such.

To make DSig a success it must be sold to the wider cryptographic and
security community. They will not judge the standard on the basis of the
features it supports but on the confidence they have in their ability
to securely implement and apply the standard.


	Phill


> -----Original Message-----
> From: w3c-ietf-xmldsig-request@w3.org
> [mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Tim Berners-Lee
> Sent: Sunday, November 28, 1999 4: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!)
>
>
>
> -----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 Monday, 29 November 1999 10:53:11 UTC