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

RE: XML-Signatures Requirements Last Call

From: John Boyer <jboyer@uwi.com>
Date: Thu, 26 Aug 1999 15:40:27 -0700
To: "Joseph M. Reagle Jr." <reagle@w3.org>, "Paul Grosso" <pgrosso@arbortext.com>
Cc: "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>, <w3c-xml-plenary@w3.org>
Message-ID: <NDBBLAOMJKOFPMBCHJOIGEPFCAAA.jboyer@uwi.com>
Have a look at Section C.1 of the fragment spec.

Note that in the FCS, the attribute of the transaction element is missing.
Is this a mistake?  I hope so.  My understanding was that the FCS would be
able to capture the entire body of ancestor information, which should
include the attributes leading up to the document root.

Regarding well-balanced regions, you've almost got it.  We need the ability
to specify a well-balanced region minus a set of well-balanced subregions
(possibly given by some sort of XPointer exclusion list).  The result still
conforms to rule 43, but the fragment element may have fewer descendant
elements than it had in the original document.

As long as the possible mistake mentioned above is in fact a mistake, then
what you have right now is the ability to give me a single element from a
document along with the ancestor information that adds context to that
element.  Your section C.1 is a great example, actually, so I hope you don't
mind if it ends up in the scenarios document!

However, suppose you have an element consisting of three subelements, of
which the first and last must appear in a signature, and the middle one must
be omitted from the signature.  For that, I seem to need to specify two
fragments in my manifest.  So when you verify a signature, it can tell the
order that the fragments are specified in the manifest, and it can tell that
neither the first nor the last item has changed, but the signature cannot
tell you which element was first and which element was last.

Now, if one were creating a hash algorithm for use in digital signature
technology, and one were able to feed it S1 = AB and S2 = BA, and the same
hash value came out for both, one would begin work on a new hash algorithm.
But creating a hash is really just an attempt to decrease the cryptographic
work.  Digital signature technology requires that whatever it is signing
should not be changeable in meaningful ways, and changing the order of
elements can radically change the meaning of a piece of XML.

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

-----Original Message-----
From: w3c-ietf-xmldsig-request@w3.org
[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Joseph M. Reagle
Jr.
Sent: Thursday, August 26, 1999 2:35 PM
To: Paul Grosso; John Boyer
Cc: IETF/W3C XML-DSig WG; w3c-xml-plenary@w3.org
Subject: Re: XML-Signatures Requirements Last Call


John Boyer has been the advocate for this requirement, so perhaps he can
speak more authoritatively. My understanding is that one needs ways of
signing portions of XML. I suspect Xlink/Ptrs could be abused in that I
could have a series of locators referencing elements with given IDs and
change the relative order of those resources within the document and the
signature would still pass -- their relative order wasn't captured by
listing the Xlinks as signature references. Excluding portions of a complete
XML document from the signature, or selecting those portions and maintaining
the context and their relative positions seem to be the two feasible
options.

Regardless, I expect well-balanced regions [1] are sufficient for the
applications I know of. To that end, the content production [2:43] rule
might even cover most of what people would want to do.

[1] http://www.w3.org/TR/WD-xml-fragment#terminology


At 16:44 99/08/25 -0500, Paul Grosso wrote:
 >At 16:53 1999 08 25 -0400, Joseph M. Reagle Jr. wrote:
 >>At 11:17 99/08/23 -0500, Paul Grosso wrote:
 >>Dependency: signing non-contigous portions of XML content in a way that
 >>retains their relative positions/context.
 >
 >I think it may be important to be clear about your non-contiguous
 >portions.  Specifically, will they be restricted to what the XML
 >Fragment spec calls well-balanced regions, or do they need to be
 >able to be un-well-balanced?  If the latter, that will probably
 >raise a lot more issues and require a lot more coordination, say,
 >with the XML Infoset and DOM and Fragments and XPointer and such
 >(since most XML processes work on a tree or node model of XML element
 >structure which wouldn't allow un-well-balanced regions).

_________________________________________________________
Joseph Reagle Jr.
Policy Analyst           mailto:reagle@w3.org
XML-Signature Co-Chair   http://w3.org/People/Reagle/
Received on Thursday, 26 August 1999 18:41:39 GMT

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