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

Re: Irvine Minutes and ost-FTF syntax proposal

From: Peter Norman <pnorman@mediaone.net>
Date: Thu, 09 Sep 1999 15:23:39 -0400
Message-Id: <4.1.19990909150458.00a78a10@pop.ne.mediaone.net>
To: "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>, <w3c-ietf-xmldsig@w3.org>
At 05:20 PM 9/7/99 -0400, Donald E. Eastlake 3rd wrote:
>
>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
>Message-ID:  <NDBBLAOMJKOFPMBCHJOICEBBCBAA.jboyer@uwi.com>
>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"?>.
>>
>><John>
>>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.)

<Peter> All I'd like to add to this is that the processing instructions are
merely labels and don't have any direct semantic effect. While it would be
reasonable to start at a start and end at an end, with Xptr you could start
three elements past an end and end two elements before a start if you were
so perverse. While we've been saying 'remove' about dsig target PIs, we may
want to be neutral between 'remove' and 'ignore for hashing'. 
>
>>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
>end=1?><sig..1../><sig..2../></doc>.

<Peter> I did in fact intend that dsig target PIs NOT be substantive. They
should be ignored for signature purposes and carry no semantics other than
location. Anything within a dsig target PI (from <? to ?> inclusive) should
be unsigned by definition. 
>
>>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
>can't.
>
>>	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
>thing.
>
>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
>>
>></John>
>
>Thanks,
>Donald
>===================================================================
> 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 15:24:55 GMT

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