Re: unparsed entities

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 basic
signature structures have to be able to sign things that are sometimes
present and sometimes absent.

If it is desired that something be bound into a signature, it suffices to
include its hash.  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.

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 17:55:23 UTC