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