W3C home > Mailing lists > Public > w3c-xml-sig-ws@w3.org > April 1999

RE: Re[2]: MIME Blobs

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>
Message-ID: <002d01be82c4$dcce96c0$0bc0010a@artemis.globeset.com>

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.


Richard D. Brown
Software Architect - R&D
GlobeSet, Inc. Austin TX - U.S.
Received on Friday, 9 April 1999 16:08:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:44:59 UTC