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