RE: Meaning of Document Closure

Hi Don,

If the debate has left a bad taste, then let me see if I can put some
sweetener on it by conceding a point I hadn't realized before.  However,
because I am obviously quite new at sweetness, there are some serious points
to consider at the end.

I am glad that the WG consensus seems to be in favor of using something like
XPath for doing exclusion, document closure, etc.  However, the reason I've
still been "persuading" is not about *whether* to use XPath but rather *how*
to use XPath.

I claimed that your method and mine were two different semantics, and you
said they were not.  My semantic is that the xpaths indicate the elements to
be signed directly.  Your method seemed to require that the xpaths indicate
the elements *between which* the signed content is located.

After a fair bit of thought I realized that it was possible to do the marker
method using the latter semantic by creating the XPath to contain a test
which said [include me if a previous sibling of ancestor or self is the
marker start element and if a following sibling of ancestor or self is the
marker end element]. Thus, you are indeed right that a different semantic
from the one I have been 'persuading' for is not necessary.  However, ...

1) This concession assumes that you meant to use the semantic I'm suggesting
and to use an appropriate xpath to achieve the marker method.  I still do
not see how my preferred semantic could be achieved with the marker method
as the native semantic.  If there is such a way, could you please spell it
out for me?

2) The fact that the marker method *can be* supported under the same
semantic does not mean that the marker method is "required" by the
applications as you previously mentioned.  The marker method is a
preference, not a requirement.  The point I've been 'persuading' for is
precisely that if you adopt the semantic I've suggested, then the tasks you
want to perform can be performed without the marker method.  I do not see
why it should leave a bad taste for me to argue that you can accomplish what
is required-- except possibly that someone would *prefer* to not recode an
existing application.  Since I will already have to recode XFDL regardless
of which semantic is chosen, I do not see this as a lot to ask so hopefully
there is some other explanation.  Either way, I will certainly be glad if we
can support the marker method within the semantic I prefer since that would
bring immediate closure to this debate, but...

3) Unfortunately, supporting the marker method as I described above implies
that we must retain the notion of sibling axes in the subset of XPath chosen
by our WG.  This in turn means that we cannot use a stack to represent
context during a single pass of the document.  One of the possible ideas for
subsetting XPath would be to throw out the sibling axes.  Why is this
important?  Well, in a previous email, I suggested this in response to
Joseph's statement that we should consider how to minimize the memory
requirements so that an implementation could fit in a smart carder reader.
If the marker method is more than a preference, and if the XPath semantic I
prefer is the one we use, then support for previous and following sibling
axes is more than a preference, and this implies that the entire document
must be in the card reader stored as a parse tree.  Not good.  It is
preferrable for a card reader to do data streaming.

In conclusion, then, hopefully you can see why I felt our xpath semantics
were different:  I was constraining the XPath node test to only using the
ancestor and self axes for reasons described directly above.

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

-----Original Message-----
From: w3c-ietf-xmldsig-request@w3.org
[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Donald E. Eastlake
3rd
Sent: Friday, September 17, 1999 10:42 AM
To: w3c-ietf-xmldsig@w3.org
Subject: Re: Meaning of Document Closure



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

Yes, it is some sort of clash because despite the fact that I, and as
far as I can tell, the consensus of the working group has agreed to
include XPath functionality in the standard so that you can do exactly
what you want, and, with somewhat less clarity, to use XPath to also
do the things you don't wnat, you keep arguing.

>I'm fine with our resulting standard
>being able to do what you want as described below, or similar things.
                                                    ^^
My "or" above should have been "and".

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

To meet a requirement, the standard has to say how to do it.  But it
seems to me that mandatoryness depends, among other things, on how
often the requirement applies and how expensive it is to meet.  There
might be a critical requirement for an essential application that is
very expensive to meet and only an idenifyable one in a hundred
deployed copies of DSIG will ever need to met.  In that case, perhaps
meeting that requirement, while it obviously must be covered in the
standard, would be optional to implement.  I'm not saying this is true
of the closure requirement you have presented, just that requirement
does not equal mandatory to implement.

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

You believe that can be done with XPath and that's the way things are
going so why do you argue so much against optional markers which just
provide another way to use XPath, a way that is not appropriate for
closure applications but is appropriate for other applications and in
particular for a different requiremet that there seems to be no other
way to met?

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

And was there a public description of the CGI script and security
system which resulted in the hole publicly distributed and subject to
public review for months?  I don't think so.

Lots of people have looked at IOTP for a long time and sepecifically
thought out this.

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

Why do you believe this is a question?  Why can't you accept that, as
far as I can tell, you have won your argument that the standard needs
to support closure?

By the way, in most protocol cases, you never have an arbitrary XML
document but a highly constrained protocol message.

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

Who said anything about two semantics or a mechanism other than XPath
(or perhaps a subset or XPointer)?  I'm just trying to clarify why you
find the inclusion in the standard of optional begin / end marker
elements that XPath could reference, and which are required to meet a
different application from yours, unacceptable.

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

The begin / end marker elements would be referenced by XPath and would
only be used for applications that don't want closure but need such
markers.  It is true that IOTP doesn't need them.

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

Yes, makers can only be used where the document can be modified.  We
have had an expressed requirement to the WG that appears to only be
meetable with such markers and it is in a case where the document is
modifyable and clsoure is not needed.  Since your requirements have
been met, wouldn't it be considerate to not argue against also meeting
other's requirements?

>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?

There are not two semantics as I understand the word.

How is a technique inferior if, in a real world situation, it is the
only one that works?  Seems to me that make it superior for that
particular application even if "inferior" in the sense that it applies
to a small minority of instances.

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

Not necessarily.  To the extent that application level software
communicates with other application level software implementing a
specific higher level protocol, they form a closed world that need
only interoperate within itself and can profile XMLDSIG as it chooses,
certainly changing optional festures to mandatory.  Competitive
pressures may force essentially all free and commercial XMLDSIG
libraries to include features or know about algorithms not listed
mandatory in the standard.  There may even be features that most
people will want that are not mandatrory because of Intellectual
Property Rights considerations.  Certainly DSA have been made the one
mandatory to implement pubic key algorithm for DNSSEC even though it
is not clear to me there will ever be an implementation that does not
include RSA, which is not mandatory.

>Could you please explain why these issues are not valid?

All issues have some level of validity.  They just mostly don't seem
applicable because you don't seem to realize that the optional markers
that are requirement by some applications are to be referenced by
XPath or the like so the capabilities you want will be included in the
standard.  And it doesn't leave a particularly good taste in my mouth
that you demand that your requirement be met by mandatory features
while arguing strenuously against even the optional inclusion of a
simple item which does not interfere with your requirement at all but
may be necessary (I don't claim this has all been fully analysed) to
meet a diffeent requirement, admitedly a different requirement not
called out in the charter.

Donald

>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 17:54:52 UTC