- From: Richard D. Brown <rdbrown@GlobeSet.com>
- Date: Fri, 9 Apr 1999 15:09:22 -0500
- To: "'David Burdett'" <David.Burdett@mondex.com>, <rhimes@nmcourt.fed.us>
- Cc: "'Signed XML Workshop'" <w3c-xml-sig-ws@w3.org>
David, Please see comments below. > Identifying the right "blob" to externally sign seems > problematical. The problem is not the definition or identification of what is being signed. This is well-defined and could be summarized by "the object being signed consists of a WEB resource that is uniquelly identified by a resource locator (c.f. XLink)." All the distinctions that you have listed are particular instances that fall under the previous description. All Web resources, XML document, XML elements, or unparsed entities are all identifiable by means of a resource locator that contains either a URI, a fragment identifier, or both. > There is therefore > a need to be able to identify the correct elements that are > being signed > even though they are not in the same document. > Correct, but this functionality is already provided by XLink/XPointer specifications. As a matter of fact, you do not have to distinguish between a local element, an external resource (XML document or other), and a external element (XML or other). They are all addressable by means of a XML Link. This is actually the reason why I have adopted an XML Link in the signature element instead of a IDREF. Thus, where you have proposed something like "http://docx?14" XLink has specified "http://docx#14". Also, recall that "href='14'" is equivalent to "href='<this>#14'" and "href='http://docx'" is equivalent to "href='http://docx#<root>'" - these equivalences are purely illustrative and certainly not normative. > > Richard's example handles the external identification of an element by > specifying, for example, "origin="http://doc1.pdf"" however, > this only works > where the name (origin) of the attribute to use is understood at the > application level by the process which needs to find it. > The problem faced by Rich has nothing to do with identification of the resource being signed. His problem has two folds: signing the raw material (pdf file for example) and being able to transport (package) the signature and a copy of the document altogether. The element package provides sufficiently for transporting an encoded version of the document. The detached-signature scheme provides for signing the raw material. But, there is no known way to bind all that together. So, we have to define a means to bind the package and the signature. At a first glance, this seems outside the scope of XML-DSIG and this is why I have suggested that it should be the object of a dedicated XML application. As I mentioned earlier, this is very similar to CMS versus S/MIME. Sincerely, Richard D. Brown Software Architect - R&D GlobeSet, Inc. Austin TX - U.S.
Received on Friday, 9 April 1999 16:08:50 UTC