Re: unparsed entities

Hi Donald,

>All the world is not a form see by a human being.  Many uses or potential
>uses of XML DSIG are for protocol messages, such as in IOTP or eCheck,
>where internal structures are being signed.  Later messages are frequently
>constructed containing some pieces and signatures from previous messages
>(which particularly motivates canonicalization in some cases).

The form is a useful paradigm in terms of getting human developers to
understand the problems that may arise in systems which are not forms based.
I use the form example because, A) I'm good at it, and B) everybody
understands it.  But transaction non-repudiation is transaction
non-repudiation regardless of how you choose to represent the transaction.
You either have or you do not have sufficient information to make assertions
about the nature of a transaction.  According to the digital signature
guidelines of the American Bar Association, a digital signature provides
authentication and authorization.  It authorizes that a given signer intends
for the transaction to have a legal effect.  If we cannot accurately say
what the transaction was, then the digital signature does not achieve its
essential purposes.

Also, based on your other email to me, let me reiterate that I've been
talking all along about the ability to sign parts of the document.  Multiple
overlapping signatures using signature filters, inclusion versus exclusion
of elements (be they form elements, structure elements, or whatever two
parties mutually decide represents a transaction).

>The basic signature structures have to be able to sign things that are
sometimes
>present and sometimes absent.

You can't sign it if it is absent.  Furthermore, how can two parties agree
on it being part of a transaction if it is absent?  How can they resolve a
dispute about the nature of the transaction if a component necessary for the
interpretation of the transaction is absent?  Although it happens in the
paper world (e.g. not actually reading the fine print), it is at least
supposed to be the case that we don't sign if we don't see the whole
agreement.

With respect to signature filters, we can't write a generic XML syntax that
prevents the developer from excluding essential pieces of an agreement
(because this requires an understanding of semantics, and XML doesn't have
that understanding).  But we can do our best to understand how signed XML
will get applied and try to make behaviors that result in good signatures
within the body of XML applications that we can envision.

>
>If it is desired that something be bound into a signature, it suffices to
>include its hash.

It does not always suffice, as you point out below, and which is the only
real point I'm trying to make.

>Whether you also need the original bits is application
>dependent. It depends on whether you want to provide and prove the original
>message or merely be able to prove there was a message and disprove false
>claims about its contents.

OK, so now I think we are agreeing.  It is necessary for a signed XML spec
to include the ability to incorporate externally defined/unparsed entities
for those applications that wish to prove the original message as a means of
achieving transaction non-repudiation.

Thanks,
John Boyer
Software Development Manager
UWI.Com -- The Internet Forms Company
jboyer@uwi.com
>
>Thanks,
>Donald
>
>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/06/99 02:38:18 PM
>
>To:   "Dsig group" <w3c-xml-sig-ws@w3.org>
>cc:    (bcc: Donald Eastlake/Hawthorne/IBM)
>Subject:  Re: unparsed entities
>
>
>
>
>
>Hi Donald,
>
>Canadian holiday yesterday.  Back in the saddle today!
>
>It may not seem so, but I think we're not that far off in our opinions.  In
>my opinion, the signature software should chase down references that were
>chased down in order to render the document.  Whether it is in a format
>that
>is opaque to XML or whether it is an XML reference, if it was necessary to
>chase it down in order to show the document to the signer, then it is
>necessarily part of the context of the signature.  Further, if the link was
>able to be resolved by the software for the purpose of rendering, then it
>is
>reasonable to require the software to follow the link again for the purpose
>of generating a message to be hashed.  Digital signatures will end in
>disservice if there is a significant difference between what the user does
>sign and what the user thinks he/she is signing.
>
>Note, however, that XFDL also has links to other documents that don't get
>dragged in and signed.  In particular, some of the links are actually
>upload
>links that tell where to submit the completed form, so the return value of
>the link would be the next form in a sequence or a "your form was received"
>notification.  It's understood that there will be cases where the link
>cannot and should not be followed.  In order to avoid some of these
>problems, XFDL used the simplest possible solution:  it doesn't allow links
>to objects that need to be included in the signature.  If you want an image
>to be rendered, you put the image in the form.  So, any actual links
>appearing in XFDL are assumed to not be required to constitute the full
>context of the transaction.  Obviously, this won't be sufficient for a
>generic signed XML specification, but by taking the view that there are two
>different kinds of links w.r.t. signatures, it should be evident that this
>is, conceptually, a variation of the signature filters problem.  A filter
>is
>a way of specifying what goes and what stays in a signature.  As soon as
>you
>give this power to form designers, you give them the power to omit the full
>context of a transaction, which can make for useless digital signatures.
>
>So, I agree with your statement that "what we want is a low level
>syntax/mechanism for signing/verifying XML and anything else."  However, it
>is not sufficient to only sign references or to pull in only a hash of the
>external entity, as I thought was being suggested in the emails to which I
>was responding.  Such a syntax must have the ability to exclude the content
>at certain links, but it *must* also have the ability to drag in externally
>defined objects as part of the signature context, and this is a point on
>which we agree based on examples in your email.
>
>In the end, it seems that because XML is devoid of semantics, it will be
>impossible for the language to prevent developers from misapplying digital
>signatures.  The best we can achieve is to make it easier to create good
>signatures and harder to create bad signatures.
>
>John Boyer
>Software Development Manager
>UWI.Com -- The Internet Forms Company
>jboyer@uwi.com
>
>
>
>

Received on Tuesday, 6 April 1999 18:35:10 UTC