Re: Irvine Minutes and ost-FTF syntax proposal

From:  "John Boyer" <jboyer@uwi.com>
To:  "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>,
            <w3c-ietf-xmldsig@w3.org>
Date:  Thu, 9 Sep 1999 15:45:23 -0700
Message-ID:  <NDBBLAOMJKOFPMBCHJOIOECCCBAA.jboyer@uwi.com>
In-Reply-To:  <199909072120.RAA08154@torque.pothole.com>

><Don>
>The specific problem to be solved was where additional elements may
>legitimately be inserted outside of the area signed so that counting
>children, for example, doesn't work.
></Don>
>
><John>
>No, the specific problems are how to achieve document closure and how to
>capture element information that is outside of the element including
>ancestor information and sibling, uncle and other information.
>I hold little hope that a *secure* system can be constructed based on
>counting positions, and I really don't think anyone could justify
>constructing such a system in lieu of identifying elements specifically.
>Once signed, paragraph three is paragraph three and if you insert a new
>paragraph before it, then the signature should break.  If you want to sign
>paragraph three regardless of changes that might be made, put a non-numeric
>identifier attribute on it.
></John>

My wording may have been a bit broad.  There are plenty of different
problems to solve and this isn't the only one.  The proposed technique
solves a particular problem that has been expressed to the working
group.  I don't accept your dismissal of that problem as something not
worthy of any of our attention.  Since none of your applications would
be inserting these markers or using Xpointers that looked for them, I
don't see how you are hurt by this.

You want to force other appliation designers to put in distinctive
attributes to mark elements.  I can't see how that is diffeent from
braketing the elements with distinctive begin/end markers.  And I'm
not convinced by your statement that it would NEVER be justified to
sign something referred to be its numeric position in a sequence.

><OrigJohn>
>>2) Processing instructions can be victimized by the c14n.  For obvious
>>reasons, it is necessary to digitally sign all information that describes
>>how the document was filtered.  So, if an application requires c14n of
>>signature content, and we use the processing instruction idea, then those
>>people will not be able to create their applications.
></OrigJohn>
>
><Don>
>I'm not quite sure what you mean here.  I think we decided on a
>pipeline so that if you apply an Xpointer that used <?dsig start="..."
>?> and <?dsig end="..." ?> and looked for specific matching "..." and
>then followed that by a canoncialization that removed PIs, you get the
>desired result assuming the application does not make other use of PIs
>and that the application does not use any signatures based on a
>canonicalization which would leave the PIs in there (since such
>signatures would fail when PIs are inserted).  (You could relax the
>restriction on other use of PIs by using a canonicalization that only
>removed dsig PIs.)
><Don>
>
><John>
>No, you do not get the desired result because someone can add arbitrary
>content between one end marker and the next begin marker.  The method lacks
>the precision to say "the document can only change by adding or modifying
>this specific element identified by tag, attribute, and ancestry".  This is
>the minimal level of specificity necessary to accommodate all XML
>applications.
></John>

Everything other than null canonicalization lacks complete "precision"
the way you use the term.  The very idea of canoncialization is to
throw away "insignificant" data and only keep the "essence" and those
terms are ultimately defined for particular applications.

><Don>
>I think he was arguing for the PI as not being "substantive" or at
>least not something which might conflict with the DTD the way an
>attribute might.  If you have a document <doc><a/><b/><c/></doc> and
>it is already partly signed this way as in <doc></a><?dsig start=1?>
><b/><c/><?dsig end=1?><sig..1../></doc> then you can still sign even
>overlapping subsets of the document as in <doc><?dsig start=2?>
><a/><?dsig start=1?> <b/><?dsig end=2?><c/><?dsig
>end=1?><sig..1../><sig..2../></doc>.
></Don>
>
><John>
>Right, but how do you achieve document closure?  There are two problems:
>1) You cannot restrict what is allowed to go between one dsig end and the
>next dsig start,

Assume you use Xpointer to extract based on element type or something.
How, in the absence of a DTD (which we cannot assume is available), are
you restricted in what you can put between such elements...

>2) You cannot restrict what gets put before the first dsig start and after
>the last dsig end for a given signature.

... or before the first or after the last.  And even with a DTD,
how are you restricted on what you can put inside such elements?

>This is the essence of why the exclusion logic is necessary.

Selecting X is identical to excluding not-X, isn't it?

></John>

It is incresingly fuzzy to me what you mean by document closure other
than that you can include signatures within the document and the tools
given applications, if they wish, to give themselves freedom to modify
unsigned portions of signed XML document are to be exaclty what you
need and no more.

><OrigJohn>
>>4) Correct me if I've misinterpreted, but the dsig:target pi seems to be a
>>hook that, for a given signature, identifies the element that is sprinkled
>>through the document markingmarking the beginnings and ends of portions of
>>the document that should be signed.  This has the following problems:
>>	a) Does not achieve document closure
></OrigJohn>
>
><Don>
>Well, it is certainly not proposed as the only technique but it seems
>to me that it can be used to achieve document closure at least to the
>extent that Xpointer can.  Just put your signatures outside the areas
>demarked by the dsig begin/end PIs but inside the document and the
>signatures don't force any change in the document type.

I had thought that enclosed signatures and not changing the type on
signing was what you meant by "closure".

></Don>
>
><John>
>This is an oversimplied view of what might happen to a document when
>multiple signatures are required.  We do not simply add more signatures.
>The XFDL example I sent up in email shows how certain other changes are
>necessary (and as you point out further below, those changes have to be very
>carefully controlled or one ends up with a security hole).
>A better example would come from a bigger document, say a form with a part
>filled out by a customer and a part that is 'for office use only'.  In this
>scenario, it should be clear that the second signer may make an arbitrary
>number of changes to the core document before affixing the second signature,
>and all of the changes should be allowed by the first signature, yet the
>first signature should be able to forbid changes that don't fit into the
>specific application context.
>So, just putting the signatures on the outside is not sufficient.
></John>

Sounds like an intersting complex case which like all such cases requires
lots of application logic.  Don't you need to either check that the
areas excluded/included in the signature are correct for the application
and/or carefully indicate to a user which is which so they can make their
own judgement?  If optional begin/end markers were defined and you didn't
want to use that technique then that wouldn't be in the types of signature
specification that were allowed and/or you would indicate the unsigned
status of material outside the brackets (perhaps for some applications
not displaying it at all).

><OrigJohn>
>>	b) Is difficult or impossible to filter external resources.
></OrigJohn>
>
><Don>
>The PI marker technique assumes you can edit these PIs into things
>being signed (and therefore assumes them to be XML).  You might or
>might not be able to do that.  The technique doesn't work if you
>can't.
></Don>
>
><John>
>Right, so why should we adopt a method that prevents certain kinds of
>applications from functioning when there is a simpler proposal on the table
>that does not have the restriction?  One may want to sign selected sections
>of selected web pages of the W3C site, but most are quite unable to make
>modifications to the W3C website.
></John>

We are not preventing any kind of application from working.  What part
of the Xpointer proposal, which I assume is what you are talking about
being on the table, is removed by defining optional elements which can
be used by applications which require them?  We would provide for
optional begin/end tags to support applications that need them.

><OrigJohn>
>>	c) Must necessarily exclude the marker elements, which loses filtration
>>information and reintroduces the same application security concerns that
>>were mentioned in objection to putting a dsig:exclude attribute on
>elements.
></OrigJohn>
>
><Don>
>When any part of something is not signed, there is reason to be
>careful.  I don't see why PI based Xpointer extraction is particularly
>worse than relative addressing Xpointer extraction (using child
>number, etc.) in this regard.
></Don>
>
><John>
>I don't buy child numbering either.  The value of XPointer comes from its
>ability to match tags, attribute values, and travel the entire parse tree if
>necessary to decide whether or not a given node should be included in the
>signed message.  If you have every conceivable way of identifying elements,
>then you have no conceivable way of restricting the types of XML
>applications that can use DSig.
></John>

Sounds great!  We don't want to restrict the types of XML applcations
that can use DSig.

Don't get hung up on your "numbering is evil" idea.  What I said above
is just as true if a distinctive attribute is used.

><Don>
>I didn't see that the dsig:exclude attribute was so terrible either
>but I don't think we want too many different ways of doing the same
>thing.
></Don>
>
><John>
>It has the same problem that you can add arbitrary content anywhere you
>want.  See my last comment below for why this is problematic.
></John>

Just as you can with most uses of Xpointer extraction.

><Don>
>If you use the dsig:exclude attribute (which I don't think is worth
>including in the standard), your application has to be designed to be
>unspoofable by such elements since a bad guy could insert them.  If
>you use begin/end PIs, your application has to be designed to be
>unspoofable by elements outside such sequences since a bad guy can
>add/delete them.  If you use Xpointer extraction, you application hs
>to be designed to be unspoofable by elements that are not extracted
>since a bad guy can manipulate them.  So what?
></Don>
>
><John>
>The 'so what' comes in how much detailed knowledge of dsig has to be
>programmed into every single application.
>I am looking for a DSig design that allows people to construct a signature
>filter that means "if the signature verified, then the document has not
>changed in any way meaningful to my application".

This is only possible for very simple applications if then.

>The PI target idea and the dsig:exclude idea both permit the modification of
>the document in ways meaningful to the application.

dsig:exclude would be problematical if it worked "automatically".  You
would need someway to turn it off.  PI target isn't any problem
because you need to explictly use it in your Xpointers or whatever and
you wouldn't do that in an application where it wasn't what you
wanted.

>This means that *every single application* will have to write in an
>application-specific 'clean-up-the-mess' routine that scans the document
>looking for bits that weren't signed to see whether any of them could make a
>difference.  Then, the logic would have to decide whether the additions were
>made maliciously or were they intended (like the office-use-only' section of
>a form).

I guess I'm unusally dense.  I just don't see your point.  You have a
source application that signes part of something.  You have a
destiantion application that verifies these signatures.  For all
practical purposes, the desination has to do many, many checks to see
if a bad guy hasn't generated a bogus message whose signature checks
but is bad in the way it is signed (or bad in lots of other
application ways).

>Then, you have the problem that every generic document processing program
>will need plugins to deal with the clean-up-the-mess routines of each
>document type simply because we didn't put in a way for signatures to be
>constructed such that signature validation implied, in and of itself, that
>the document could be accepted.

I thought that you thought that Xpointer did provide "a way for
signatures to be constructed such that...".  Exactly how does adding a
section somewhere defining optional marker elements change that?
Since the Xpointers are signed, they can't be diddled in legitimate
messages.  Even without such markers, Xpointer is plenty powerful
enough to write signatures that verify an insigniciant portion of a
message allowing vast changes.  The receiver has to do lots of checks
that any signature Xpointers present are legit in any real world
application that uses them unless it trusts the sender.  But if it
trusts the sender that much, it can assume the sender has signed
properly with a signature covering all that is needed.  You seem to
believe such proper signatures with adequate constraints can be
constructed with Xpointer so presumably trusted senders would do that
(and, in your view, never use begin/end markers of any sort) so you
can just verify the signature and stop worrying.

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

Donald
===================================================================
 Donald E. Eastlake 3rd   +1 914-276-2668   dee3@torque.pothole.com
 65 Shindegan Hill Rd, RR#1  +1 914-784-7913(w)     dee3@us.ibm.com
 Carmel, NY 10512 USA

Received on Tuesday, 14 September 1999 11:19:14 UTC