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

RE: Irvine Minutes and ost-FTF syntax proposal

From: John Boyer <jboyer@uwi.com>
Date: Thu, 9 Sep 1999 15:45:23 -0700
To: "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>, <w3c-ietf-xmldsig@w3.org>
The specific problem to be solved was where additional elements may
legitimately be inserted outside of the area signed so that counting
children, for example, doesn't work.

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.

>2) Processing instructions can be victimized by the c14n.  For obvious
>reasons, it is necessary to digitally sign all information that describes
>how the document was filtered.  So, if an application requires c14n of
>signature content, and we use the processing instruction idea, then those
>people will not be able to create their applications.

I'm not quite sure what you mean here.  I think we decided on a
pipeline so that if you apply an Xpointer that used <?dsig start="..."
?> and <?dsig end="..." ?> and looked for specific matching "..." and
then followed that by a canoncialization that removed PIs, you get the
desired result assuming the application does not make other use of PIs
and that the application does not use any signatures based on a
canonicalization which would leave the PIs in there (since such
signatures would fail when PIs are inserted).  (You could relax the
restriction on other use of PIs by using a canonicalization that only
removed dsig PIs.)

No, you do not get the desired result because someone can add arbitrary
content between one end marker and the next begin marker.  The method lacks
the precision to say "the document can only change by adding or modifying
this specific element identified by tag, attribute, and ancestry".  This is
the minimal level of specificity necessary to accommodate all XML

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

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,
2) You cannot restrict what gets put before the first dsig start and after
the last dsig end for a given signature.

This is the essence of why the exclusion logic is necessary.

>4) Correct me if I've misinterpreted, but the dsig:target pi seems to be a
>hook that, for a given signature, identifies the element that is sprinkled
>through the document markingmarking the beginnings and ends of portions of
>the document that should be signed.  This has the following problems:
>	a) Does not achieve document closure

Well, it is certainly not proposed as the only technique but it seems
to me that it can be used to achieve document closure at least to the
extent that Xpointer can.  Just put your signatures outside the areas
demarked by the dsig begin/end PIs but inside the document and the
signatures don't force any change in the document type.

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.

>	b) Is difficult or impossible to filter external resources.

The PI marker technique assumes you can edit these PIs into things
being signed (and therefore assumes them to be XML).  You might or
might not be able to do that.  The technique doesn't work if you

Right, so why should we adopt a method that prevents certain kinds of
applications from functioning when there is a simpler proposal on the table
that does not have the restriction?  One may want to sign selected sections
of selected web pages of the W3C site, but most are quite unable to make
modifications to the W3C website.

>	c) Must necessarily exclude the marker elements, which loses filtration
>information and reintroduces the same application security concerns that
>were mentioned in objection to putting a dsig:exclude attribute on

When any part of something is not signed, there is reason to be
careful.  I don't see why PI based Xpointer extraction is particularly
worse than relative addressing Xpointer extraction (using child
number, etc.) in this regard.

I don't buy child numbering either.  The value of XPointer comes from its
ability to match tags, attribute values, and travel the entire parse tree if
necessary to decide whether or not a given node should be included in the
signed message.  If you have every conceivable way of identifying elements,
then you have no conceivable way of restricting the types of XML
applications that can use DSig.

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

It has the same problem that you can add arbitrary content anywhere you
want.  See my last comment below for why this is problematic.

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?

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".
The PI target idea and the dsig:exclude idea both permit the modification of
the document in ways meaningful to the application.
This means that *every single application* will have to write in an
application-specific 'clean-up-the-mess' routine that scans the document
looking for bits that weren't signed to see whether any of them could make a
difference.  Then, the logic would have to decide whether the additions were
made maliciously or were they intended (like the office-use-only' section of
a form).
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.

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


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

 Donald E. Eastlake 3rd   +1 914-276-2668   dee3@torque.pothole.com
 65 Shindegan Hill Rd, RR#1  +1 914-784-7913(w)     dee3@us.ibm.com
 Carmel, NY 10512 USA
Received on Thursday, 9 September 1999 18:47:32 UTC

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