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

RE: Meaning of Document Closure

From: John Boyer <jboyer@uwi.com>
Date: Fri, 17 Sep 1999 09:36:16 -0700
To: "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>, "DSig Group" <w3c-ietf-xmldsig@w3.org>
Message-ID: <NDBBLAOMJKOFPMBCHJOIIEDOCBAA.jboyer@uwi.com>


-----Original Message-----
From: w3c-ietf-xmldsig-request@w3.org
[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Donald E. Eastlake
3rd


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.

<John>
It's not a clash.  In my opinion, the difficulty arises in being convincing
to some that there are things other than protocol messages that also have to
be signed.  The reason this is not a clash is because the techniques I'm
suggesting do not in any way prevent the efficient signing of protocol
messages.  In fact, it seems that the method I'm suggesting would be
slightly more efficient, and I'd appreciate an explanation to the contrary.
</John>

I'm fine with our resulting standard
being able to do what you want as described below, or similar things.

<John>
That's great!
</John>

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.

<John>
I guess I'm still not getting the use of the term 'requirement' in
situations where 'mandatoryness' is not yet decided.
Still, I can't wait to see the doubts about XPath, and I'm sure the XPath
folks will be quite interested in the feedback, too.
</John>

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


<John>
I am actually using 'document' in the same sense that you are.  We are
designing software that will sign an arbitrary XML documents in totality or
in part.
As stated above, this isn't about the fact that some subset of XML extension
languages "don't give a damn" about document closure.  This is about the
degree to which an arbitrary XML document can be secured in whole or in part
by our signature specification.
</John>

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.

<John>
How long was the hotmail security hole around before there was a complaint?
Two seconds is too long.
Furthermore, the point here is not whether the design of a specific
application like IOTP is such that no security holes could crop up from the
addition of information in the unsigned regions.
The question is, given an arbitrary XML document (in other words, you don't
get to know the vocabulary and semantics when you answer this question), can
you guarantee that security problems will not come up for the application if
information is added to the unsigned regions?  Of course not because the
application is not specified.  Hence, we need a way for signatures to be
created that forbid modifications to unsigned regions if such modifications
could hurt the application.  But once again, we don't know the application,
so we need something like XPath that allows the actual filter to be
constructed by someone with knowledge of the application.
</John>

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.

<John>
I agree! But how does this substantiate the point that we should have two
different semantics for how the message to be signed and verified is
generated?  How does using a single XPath to directly filter the document
prevent you from doing what you need to do?
</John>

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.

<John>
The main objections I've raised are

1) The begin/end marker approach doesn't result in document closure, which
you agreed was useful to some applications, in particular those involving
transactions among people rather than machines.  A direct XPath application
can solve protocol signing problems like IOTP using inclusive logic, and it
can provide document closure for applications that need it.
2) The begin/end marker approach requires the addition of markers in
documents to which a signer may not have access, whereas a direct XPath can
indicate portions of such documents without modifying them.
3) Why do we need more than one semantic for how to generate the message to
be signed/verified?  If one is found to be inferior (e.g. in the ways
described above), why shouldn't it be discarded?
4) If there are multiple methods, then some could be labelled mandatory
while others are labelled optional.  The mandatory ones will be used even if
they are not the best fit in terms of security because of the need for
interoperability.

Could you please explain why these issues are not valid?

Thanks,
John Boyer
Software Development Manager
UWI.Com -- The Internet Forms Company

</John>

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 12:39:28 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:07 GMT