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

Re: Irvine Minutes and ost-FTF syntax proposal

From: Donald E. Eastlake 3rd <dee3@torque.pothole.com>
Date: Tue, 07 Sep 1999 17:20:28 -0400
Message-Id: <199909072120.RAA08154@torque.pothole.com>
To: <w3c-ietf-xmldsig@w3.org>

From:  "John Boyer" <jboyer@uwi.com>
To:  "Peter Norman" <pnorman@mediaone.net>, <w3c-ietf-xmldsig@w3.org>
Date:  Fri, 3 Sep 1999 14:10:13 -0700
In-Reply-To:  <4.1.19990903151958.00a775a0@pop.ne.mediaone.net>

>Peter said:
>I don't want to get into a discussion of how accurately the minutes reflect
>the actual remarks of the participants, but  I do want to say that I am not
>in favor of any form of exclude tag. What I would like to see are
>processing instructions that can serve as reference points on which to base
>whatever form of pointer we decide to use. There is no guarantee someone
>signing a document will be able to make any substantive changes, since
>either the DTD might not allow this or the document may already be signed.
>Since it is also possible that the portion to be signed doesn't have a
>unique ID, we need some construct that people can add as a reference for
>pointers, that is not included in the hash. This would allow multiple
>overlapping signatures on arbitrary XML documents. I think the word
>'element' attached to dsig:target is misleading. I would prefer processing
>instruction. Something like
><?dsig target="xxx"?>.
>1) The Xpointer based extract tag allows multiple overlapping signatures
>using the exact commands demonstrated in the FTF.  Furthermore, those
>Xpointers can be constructed without needing to rely on uniquely identified
>elements (Xpointers can count children, siblings, ancestors, and descendants
>if necessary, and they can compare on tag name, attribute value or character
>content, and they can combine multiple filtering conditions using the three
>standard logical operators).

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.

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

>3) <Peter>There is no guarantee that someone signing a document will be able
>to make any substantive changes, since either the DTD might not allow this
>or the document may already be signed.</Peter>

>(John)I do not see how this substantiates anything related to security since it is
>quite a different statement than "There is a guarantee that noone signing a
>document will be able to make substantive changes...".

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

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

>	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

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

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

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?

>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 Tuesday, 7 September 1999 17:20:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:09:56 UTC