Re: Meaning of Document Closure

John,

Thanks for this explanation.  Now that I understand what you mean by
closure, I think that this is all something very close to the document
versus protocol viewpoint clash.  I'm fine with our resulting standard
being able to do what you want as described below, or similar things.
There remains the questions of whether XPointer / XPath or subset is
adequate / inadequate and mandatory / recommended / optional but I'd
like to nail down what facilities will meet requirements before
deciding on mandatoryness.  I'm not so sure anymore about XPath
etc. and will post a separate note on why I have doubts.

Equallty important is the fact that many applications don't give a
damn about document closure.  IOTP, for example, never cares about it
and always signs only selected sub-parts of the XML documents it
exchanges ("document"s in the XML definition sense, not in the sense
that a normal human being is every likely to try to read one).  As a
result, it is trivial for a bad guy who can mess with transmssions to
stick stuff into various unsigned parts of IOTP messages.  But there
has never been any complaint on the TRADE WG mailing list that this is
a problem.  Even if you assumed it was and you added a signature over
the entire document other than the signature, you would still need
signatures over parts of the document because in many cases parts of
the document are forwarded and the signature on those parts need to be
verified.

Given that there is a requirement for such "non-closure signatures" it
hardly matters to any of the points you were making if the part signed
is designated by a particular attribute in a signed element, by
particular begin/end attributes that braket or begin and end a signed
element sequence, or if we define options marker elements that can be
used to bracket a signed element sequence.  I see no reason not to
permit all of these.

Thanks,
Donald

From:  "John Boyer" <jboyer@uwi.com>
Resent-Date:  Tue, 14 Sep 1999 11:55:46 -0400 (EDT)
Resent-Message-Id:  <199909141555.LAA21326@www19.w3.org>
To:  "Joseph M. Reagle Jr." <reagle@w3.org>,
            "DSig Group" <w3c-ietf-xmldsig@w3.org>
Date:  Tue, 14 Sep 1999 08:53:42 -0700
Message-ID:  <NDBBLAOMJKOFPMBCHJOIMECOCBAA.jboyer@uwi.com>

>Thanks, Joseph.  I'm using the term closure as appropriate to the
>application, but given the number of closures there are in computing and
>mathematics (six others come to mind without having to consult any books), I
>should've spelled this out in the scenario.
>
>Closure has such a generic meaning in common language, so it can be applied
>in many different domains.  The common language usage of the term closure is
>as a noun for the act of closing or finishing (e.g. "We would like closure
>on this specification process as soon as possible").
>
>The current XFDL filters are designed to specify the precise conditions
>necessary to close or finish a document.  Thus, if person A signs an
>unfinished document, then the signature filters can be set up to describe
>precisely what is allowed to change after Person A's signature in order to
>achieve closure on the document.  If Person B deviates from the described
>changes, then this should be equivalent to deviation from the intent of the
>application, and should therefore result in the invalidation of Person A's
>signature.
>
>Of course, this means that signature A must be able to specifically define
>what should be omitted since that is precisely what may be added to close
>the document.  From an algorithmic standpoint, this design also implies the
>need to scan the entire document looking for things that match a filter,
>which is reminiscent of other closure operations in computing.  With only
>inclusion logic such as we had in the original manifests of the Brown draft,
>one did not need to scan the entire document but could conceive of using
>short-circuits if they were available.
>
>Note that this design still puts the onus on the application developer to
>set up a filter properly, but if an application has a security hole, it is
>not because the core dsig syntax (or perhaps some branch of it) is not
>sufficiently powerful to express document closure, but rather because the
>application designer did not express it properly.
>
>By analogy, the following C code snippet crashes
>
>    char *P=NULL; ... *P = '\0';
>
>The fact that C is a standard does not mean the application developer can't
>write bugs.  What it means is that a committee and a larger community have
>come to a consensus that the language is sufficiently powerful to express
>all computer programs that fit the language design requirements.
>
>By comparison, XML DSig has requirement 3.1.3 stating the need to sign XML
>resources in totality or in part.  To put it another way, we want to
>*securely sign partial and total XML resources*.   Since application
>designers are able to define part of the language that is being signed (the
>keywords used by their brand of XML), our task is simply to provide
>mechanisms that allow secure signatures to be created regardless of the
>particular well-formed XML grammatical constructs that are selected by the
>application designer.  Otherwise, we are deciding to sign a subset of
>well-formed XML and must go to the trouble of defining that subset and then
>considering whether the subset is sufficiently powerful
>to express the types of signatures that the community at large will need to
>create.
>
>Guaranteeing data integrity among communicating computers is only one
>application of digital signatures; a larger application to be considered
>should be the use of digital signatures in service of society, whose primary
>need for signatures is for documents.  Finally, since any document that must
>be signed represents an agreement of some sort between two or more parties,
>it is reasonable to assume that no small fraction of these documents will
>require multiple overlapping signatures.  As such, the notion of document
>closure would seem to be indispensable as a method of providing appropriate
>security for such documents.
>
>John Boyer
>Software Development Manager
>UWI.Com -- The Internet Forms Company

Received on Friday, 17 September 1999 00:22:36 UTC