- From: John Boyer <jboyer@uwi.com>
- Date: Tue, 17 Aug 1999 14:00:10 -0700
- To: "DSig Group" <w3c-ietf-xmldsig@w3.org>
-----Original Message----- From: Joseph M. Reagle Jr. [mailto:reagle@w3.org] Sent: Tuesday, August 17, 1999 12:55 PM To: John Boyer Cc: Daniel Veillard Subject: did you ever send your comments to fragments? No, Joseph, I haven't, but see below. (Also, Daniel just wrote to inform me that it was considered and dropped by the WG with the note that it could be possible in a future version. He has sent a note to Paul Grosso about reconsidering this) At this point I am not sure where the problems I describe should be handled, though I feel the best place is in the fragment spec because it already solves so much of the problem. I really like what fragments do in terms of capturing ancestor element information. I think it is very difficult to sign an element within an XML resource without knowing the full context. The depth of an element can have meaning. The particular tags in the ancestor path can have meaning. The attributes of the ancestors can have meaning. Identifying a fragment in a resource is a good way of dealing with these issues. The thing I don't know is whether current c14n algorithms can handle a fragment (for starters). Until we know whether our system will use fragments, it doesn't seem that I have a case for bothering them with the one thing that fragments don't do. The only problem fragments don't solve is how to indicate non-continuous portions of an XML document. Using separate fragments doesn't solve the problem because the order in the manifest may not be the order in which the elements appear in the XML resource. Often when I need to sign XML, I need to exclude parts of a number of element while retaining the order of the portions of the document that I do keep. A recent email from Richard Brown suggested that the exclusions to which I refer could be placed as algorithm parameters to a specialized c14n algorithm. Good point, but I don't like this approach at all because I want all signatures generated by signed XML to be verifiable in an application-independent fashion. The c14n needs to be part of a W3C standard or we miss the boat on globally secure resources. Another possibility is that XPointer has just been overhauled, and I'm told (haven't read it yet) that one can now span non-continuous regions with the same XPointer. Since our resource locators will be XLinks, this would seem to solve the problem except that nothing about XPointer rendition suggests that they have to keep the ancestor information retained by a true fragment. Ideally, the fragment spec would be modified to allow the specification of multiple portions of the document that would be put together in the same order when the fragment is constructed. There, comments sent! John Boyer Software Development Manager UWI.Com -- The Internet Forms Company
Received on Tuesday, 17 August 1999 17:00:58 UTC