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

Re: unparsed entities

From: John Boyer <jboyer@uwi.com>
Date: Tue, 6 Apr 1999 11:38:18 -0700
Message-ID: <003401be805c$a4442af0$9ccbf4cc@kuratowski.uwi.bc.ca>
To: "Dsig group" <w3c-xml-sig-ws@w3.org>
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
Received on Tuesday, 6 April 1999 14:33:42 UTC

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