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: Fri, 3 Sep 1999 14:10:13 -0700
To: "Peter Norman" <pnorman@mediaone.net>, <w3c-ietf-xmldsig@w3.org>
Message-ID: <NDBBLAOMJKOFPMBCHJOICEBBCBAA.jboyer@uwi.com>
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).

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.

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

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
	b) Is difficult or impossible to filter external resources.
	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.

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

</John>
Received on Friday, 3 September 1999 17:11:51 GMT

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