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

Re: unparsed entities

From: <dee3@us.ibm.com>
Date: Fri, 2 Apr 1999 17:24:44 -0500
To: "Dsig workshop" <w3c-xml-sig-ws@w3.org>
cc: xml-dsig@socratic.org
Message-ID: <85256747.007C2290.00@D51MTA10.pok.ibm.com>

What you are saying might be pretty close to right for something whose sole
purpose in life is to sign simple on line forms.  But I think what we want
is a low level syntax/mechanism for signing/verifying XML and anything

I believe it is incorrect to say that this mechanism should always chase
down every external reference.  First of all, it needs to be able to sign
arbitrary opaque quantities that are completely incomprehensible to it so
it can't possible even tell when all the external references are.  Second,
whether an external reference should be followed depends on the particular
action.  Sure, maybe for human HTML forms signing, you should always chase
down images.  But what about a hunk of *ML that has an HTTP URL in the
middle.  Should that be followed if you are signing the hunk?  Only
something that understands the exact semantics of the situation can know.
The surreounding *ML might say here is a pointer to the contract you are
agreeing to.  Or it might say this URL points to whatever the current
version of the XML XLink draft is (<http://www.w3.org/TR/WD-xlink>).  In
the first case, the signature probably needs to cover the resource pointed
to.  In the second, it is clearly wrong for it to.  There are much worse
cases than this.  Suppose you have a pointer to a web page that is
interactive and accepts a selector and then displays various other web
pages.  It might be that that whole tree is important and should be bound
into the signature of the initial page.  Or it might now be.  But if you
just try to follow it recursively, it will sure take you a long time if its
a pointer to www.yahoo.com....

An XML signing/verifying machine should be a box that can be called from a
forms signing service.  Its up to the particular forms signing service what
resources it feeds into the signature.

The same for other circumstances.  The signing box can't be expected to
understand what's going on.  It's up to the users of it to decided what to
feed it, including items referenced out of other items.

Donald E. Eastlake, 3rd
17 Skyline Drive, Hawthorne, NY 10532 USA
dee3@us.ibm.com   tel: 1-914-784-7913, fax: 1-914-784-3833

home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
dee3@torque.pothole.com   tel: 1-914-276-2668

"John Boyer" <jboyer@uwi.com> on 04/01/99 07:29:43 PM

To:   "Dsig group" <w3c-xml-sig-ws@w3.org>
cc:    (bcc: Donald Eastlake/Hawthorne/IBM)
Subject:  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
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
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
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
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
this letter.

John Boyer
Software Development Manager
UWI.Com -- The Internet Forms Company

    -----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


    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
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
has been provided with adequate information before signature.


    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
transform unparsable entities into character content for inclusion in the
hash value.  It is important to capture non-human-readable resources such
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
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
change positions.  This could alter the meaning of the agreement.

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

        John Boyer
        Software Development Manager
        UWI.Com -- The Internet Forms Company
Received on Friday, 2 April 1999 17:37:40 UTC

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