W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > July to September 1999

Meaning of Document Closure

From: John Boyer <jboyer@uwi.com>
Date: Tue, 14 Sep 1999 08:53:42 -0700
To: "Joseph M. Reagle Jr." <reagle@w3.org>, "DSig Group" <w3c-ietf-xmldsig@w3.org>
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

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

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 Tuesday, 14 September 1999 11:55:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:31 UTC