RE: Irvine Minutes and ost-FTF syntax proposal

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

<John>
I'm not dismissing the problem, I'm saying that there is a different
solution that is both more efficient and doesn't cause numerous problems
that I have stated repeatedly and are not yet refuted.
Furthermore, I am not 'hurt' by Peter's proposal unless it becomes the only
way to do things.  My claim is that everyone would be hurt by it because A)
the markers are omitted and B) arbitrary content can be added between the
markers.  The latter point is particularly damaging to applications as it
does not achieve document closure.
</John>

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.

<John>
Saying that I hold little hope for the security of such applications is not
the same as saying "NEVER".
Furthermore, isn't the working group saying that users will be 'forced' to
put a distinctive attribute if they want to use a frag ID?

I DO NOT want to force designers of XML vocabularies to do anything.  I want
to persuade the WG to put enough flexibility in place so that designers of
XML vocabularies who want to sign portions of documents expressed in their
vocabularies *have the ability* to do so in a  secure fashion *without our
having to define constraints on their vocabularies*.

This is an important point if I am being accused of 'forcing' something
because the very thing I want is to 'persuade' the working group NOT to
force constraints on XML vocabularies that will be designed for signature in
the future.
</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.

<John>
As Phill pointed out in past emails, XML c14n should only throw away data
that is insignificant to XML.  Perhaps applications can define their own
c14n, but we seem to have adopted the term transformation for this.
The reason for this different terminology is that it is not an
application-specific c14n but rather a document specific transformation.
Given a particular XML vocabulary, there will be lots and lots of instances
where the application processing the vocabulary will not know what is
important and what isn't because it depends on the specific document
expressed in that vocabulary.  See my post on the meaning of document
closure for an example.
</John>

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

<John>
XFDL usu. does not use a DTD unless required by some intermediary XML
software other than ours because XFDL permits several language features that
cannot be expressed by DTD's (e.g. extensions to the vocabulary, uniqueness
of children combined with arbitrary order of children, infix compute
expressions).
The point is that despite the lack of a DTD it is possible to be quite
precise about exactly what is allowed and what isn't.  To see an example of
an XPtr that is reasonably precise, please see my post on the XFDL example.
</John>

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

<John>
No, and this is the essence of my point about document closure.
When you select X from universe U you can validate X regardless of what
happens to U.  When you exclude not-X you can validate X but also guarantee
that only specific things have happened to U.
</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.

<John>
The hurdle here is the extent that one has precision in defining the
unsigned portion of the document.  To precisely define the unsigned portion,
one may need to put conditions on an elements tag value, attribute values,
and the tags and attributes in the chain of ancestry of the element.  This
was all I found to be necessary to XFDL, but perhaps others have opinions
about further necessities.
</John>

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

<John>
No, that's just 'unenveloped' signatures.
</John>

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

<John>
It does not seem to be complex using an XPath such as the one in my XFDL
example post.  Nor does it require lots of knowledge on the part of XFDL
processors.  It requires that the person creating the XFDL document should
have adequate knowledge of the document being created.  The document creator
sets up a filter that precisely defines the additional changes that can be
made before the document is closed.

Finally, how that information is presented to the user is clearly beyond the
scope of the WG, but I do not see how my statements have implied that it
should be addressed.
</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.

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

<John>
I am not talking about most uses of XPointer, but rather a specific use of
XPointer that does not, in fact, have the problem.
What I'm proposing is that instead of using XPointers to point at marker
elements, use the XPointer to directly identify the portion of the document
to be signed.  If this is done using the XPointer in the XFDL example, the
result is that the problem of arbitrary content meaningful to the XFDL
viewer CANNOT be added to the form without breaking the signature.
</John>

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

<John>
Au contraire.  The filter defined in the XFDL example can be used on forms
of arbitrary size.  Furthermore, the set of nodes omitted from a document
can become arbitrarily larger yet precisely defined by simply writing a
bigger test in the square brackets.  As soon as you have all logical
operators and all comparators along with the assumption of iterating the
elements in the whole document, the idea scales to problems of arbitrary
complexity.  This is not to say that the work of the WG will be complex; no,
as with the marker idea, the complexity is offloaded to the document author,
which is where it should be.
</John>

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

<John>
The many, many checks can amount to checking the hash if the semantic for
constructing the message to be verified is to scan the document and add
everything matching an XPointer that is expressed as exclusionary logic.

Then, if there is a security problem, it is the problem of the document
author who wrote the Xpointer rather than a problem with XML digital
signatures themselves.  Nothing specific to the application can be added
without the permission of the XPointer filter.
</John>

>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>
I agreed that XPointer as used in the way I defined at the F2F and above
would be sufficient.  It should be clear by now why the marker element idea
changes everything.  To reiterate for completeness' sake, you can add
arbitrary content between the marked regions, which puts a great onus on the
application to make these additional checks you are talking about.  By
comparison, if the Xpointer directly describes a node test for the elements
themselves, then the validation of the resulting message's hash directly
tests whether or not the document has changed in ways that would impact the
interpretation of the signature within the given document/application
context.

If ever a signature were repudiated in a court, two things would happen.
First, there would be a check of the hash.  Then there would be an
examination of whether the filter adequately protected the document from
unintended changes.  If a marker approach is used, that examination would
then have to extend to a detailed examination of the application logic.  The
term reasonable doubt comes to mind.  We can either require each application
designer to create the notion of document closure within their respective
application frameworks, or we can apply the XPointer directly to the
document and given everyone a unified approach to document closure
specification.

Finally, I do not understand what you mean when you say that a trusted
sender would not use marker elements.  It is my understanding that there
will only be one semantic.  You either want to sign what the XPointer
indicates, or you want to sign what is between the elements indicated by the
XPointer.  If you are talking about supporting both semantics?  This would
be OK insofar as I could then at least create signatures that I perceive are
secure, but it would still be worrisome in that those who chose the marker
design would still have the problems on their hands that I've mentioned
previously.  If, for example, only the marker method were selected as
mandatory then that would be almost equivalent to not bothering with the
second semantic since there would not be interoperability.

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

Received on Tuesday, 14 September 1999 15:12:48 UTC