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

Re: unparsed entities

From: <dee3@us.ibm.com>
Date: Thu, 8 Apr 1999 13:23:58 -0400
To: Signed XML Workshop <w3c-xml-sig-ws@w3.org>
cc: xml-dsig@socratic.org
Message-ID: <8525674D.006452CF.00@D51MTA10.pok.ibm.com>



"John Boyer" <jboyer@uwi.com> on 04/06/99 06:39:45 PM

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

### Like any paradigm, it can also sometimes mislead.  Not all
communication
is between mutually hostile entities nor do all recipients always require
signatures.  If a message is sent from A -> B things referenced out of
parts
of the message, even if essential to the meaning, need not be included or
signed if A trusts B to already have those things.  And it would be
perfectly reasonable to just ship the signature from A to B if you were a
bit more paranoid and wanted B to check that the thing refered to had not
changed, still not sending the actual signed data from A to B each time.
And, of course, all this still applies if the message actually flows
A -> C -> B even if it is stored at C for a while.

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.

### While you can't construct or verify the signature of data you don't
have, you can certainly include such a signature without the signed data
in a message and a general standard needs to provide for that.  You seem to
always assume that these transaction messages are monolithic and that all
parts are always needed.  What if a message included a choice on the
part of the recipient such that some of the data was needed if one choice
was taken and some if another choice was taken?  Assume A sends this
message
to B that makes the choice and then forwards it to C.  Computationally, you
don't want to have N separate signatures in the message because each can
be expensive to calculate.  Instead, you want all the hashes of the various
optional pieces there and then you want to sign them all.  The unnecessary
pieces of data can then be dropped by B, which might be a substantial
savings in some cases.  C would get the data needed for the choice that B
made and would get a signature structure that authenticates all the data,
both that present and that absent.  In fact, B's choice might determine
which of serveral Cs the message parts are sent to.  (This sort of thing
is provided for in Richard Brown's draft.)

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

### If you are designing a message, you need to be able to include in it
all the data it needs.  This includes a signature structure if you need
that.  And a general signature structure needs to be able to specify data
anywhere that it is signing.  And I suppose a signature structure could
even provide for optionally including signed data within the structure,
although I don't see that as necessary.  But I don't think the signature
primitive can pick the things that need to be signed and/or included.

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

### Donald
>
>"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 Thursday, 8 April 1999 14:16:38 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 11:28:03 EDT