Re: unparsed entities

Hi Richard,

Thanks for the feedback. However, I don't think an unambiguous reference is
going to do the trick in a practical sense because a reference does not lock
the resource into position on the net or prevent it from being changed.
Stylesheets, images, etc. are a necessary part of running real applications
over time, yet a digital signature that must stay in effect over a long time
cannot permit such changes.  And having a hash of an external entity does
solve the problem because hashing functions are one-way.  It is not possible
to use the hash to reconstruct the object, which means that it is still not
possible to render the disputed agreement.

Furthermore, I don't think it is accurate to say that this limitation makes
it difficult to elaborate and promote general purpose form processing
standards and tools since XFDL itself contradicts that point of view.  To
wit, XFDL's current solution to the limitation is to collect all relevant
presentation layer elements including images and elements of style into a
single object, the form.  A second solution, which is discussed in section 1
of the position paper appearing at
http://www.w3.org/DSig/signed-XML99/pp/signedxml.htm, is to collect all
external objects and bring them in as subelements of the signature element
being created.  Either of these approaches eliminates the problem of
resources being changed or moved in the future.  We want a snapshot
mentality, like paper forms.  Just because a company changes its logo
doesn't mean that signatures on old forms are invalid, but it also does not
mean that the logos on those old forms will change.

Now, to be fair, signature filters greatly complicate matters, but that's
another story so in the interest of brevity, I won't enumerate the issues in
this letter.

Thanks,
John Boyer
Software Development Manager
UWI.Com -- The Internet Forms Company
jboyer@uwi.com

    -----Original Message-----
    From: Richard D. Brown <rdbrown@GlobeSet.com>
    To: 'John Boyer' <jboyer@uwi.com>; 'Dsig group' <w3c-xml-sig-ws@w3.org>
    Date: Thursday, April 01, 1999 2:39 PM
    Subject: RE: unparsed entities


    John,

    You do not necessarily have to embed a copy of the entity into the XML
document in order to bind the entity to the content being signed. An
unambiguous reference that includes among others the hash of the entity
could serve a similar purpose.

    Your second comment tends to reinforce my feeling that it will be
difficult to elaborate and promote "general purpose" form processing
standards and tools. Since the data being signed my differ significantly
from the one being displayed to the user, it will be quite difficult to
ensure that relevant pieces of information have been clearly and
unambiguously disclosed to the user.

    One could argue that a "general purpose" standard could mandate that the
pieces of information being signed shall be displayed to the user before
signature. This is the option currently adopted by Netscape Communicator
during form signing. The drawback of this solution is that you end up
signing at the presentation layer (the data being signed should be readable
and understandable by the reader). Thus, I strongly feel that, unless the
standard provides a secure means to refer on a per application basis to a
trusted style-sheet (or the like) it seems that dedicated viewers will
provide a better solution. Notice that this does not imply different
signature procedures. The specifics are limited to making sure that the user
has been provided with adequate information before signature.

    Sincerely,

    Richard D. Brown
    Software Architect - R&D
    GlobeSet, Inc. Austin TX - U.S.

     -----Original Message-----
    From: w3c-xml-sig-ws-request@w3.org
[mailto:w3c-xml-sig-ws-request@w3.org]On Behalf Of John Boyer
    Sent: Thursday, April 01, 1999 11:54 AM
    To: Dsig group
    Subject: Re: unparsed entities


        Hello all,

        Regardless of how an unparsed entity is indicated, a copy of the
entity must be brought into the XML document.  XFDL uses base 64 encoding to
transform unparsable entities into character content for inclusion in the
hash value.  It is important to capture non-human-readable resources such as
images in the hash as an essential part of capturing the context leading to
a signature.  The user does not see start tags, attributes, and character
content.  In a legal sense, a user who affixes a digital signature is
authorizing that *what they are looking at* is correct.  It is necessary to
combine the input values given by the user with the questions asked,
foreground and background colors, fontinfo, images, GUI object locations,
etc.  A repudiation argument could then include graphically rendering the
hashed message.

        Here's an example.  Suppose we didn't include images in the
signature.  This could be the image that tiles the background, the image of
the company logo, the image that shows which credit card will be used, a
drawing or picture of what is being negotiated, etc.  Removing the image can
directly alter the meaning of the transaction, and it is even possible to
have indirect consequences.  For example, not having the image could cause
other objects whose positions are based on the image's bounding rectangle to
change positions.  This could alter the meaning of the agreement.

        If only a reference to the object is kept, then the object can never
be moved.  If it does, then changing the reference breaks the signature.


        John Boyer
        Software Development Manager
        UWI.Com -- The Internet Forms Company
        jboyer@uwi.com