Re: [w3c-ietf-xmldsig] content inclusion

See comments after @@@ below...

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 07/21/99 07:12:08 PM

To:   "DSig Group" <w3c-ietf-xmldsig@w3.org>
cc:
Subject:  [w3c-ietf-xmldsig] <none>






> >... which just goes to show that "the content of a Web resource"
> >is a definite description error, like saying "the arm of the man."
> >Which arm?

>I don't buy this. To the question of "which arm" the answer is the arm with
>the following fingerprint (hash).

Yes, but we don't want a digital signature system that has to search around
for something matching a given hash until it finds the content that the
signature 'must have' been referring to.

@@@ I believe URI's are supposed to point to a specific "resource".  But it
really all depends on the "scheme", the part before the ":".  For example, I'm
not sure what you could hash, other than the URI itself, if someone was trying
to sign <telnet:example.com>.

If a signature is created that includes a hash of something indicated by the
URI, and someone later changes the content at the URI, then the signature is
broken.  When the content addressed by a URI is known to be volatile, the
only reasonable option is to take a copy of the content and put it into the
document.

@@@ You are making enormous assumptions here and, I believe, basicaly taking the
"human document" point of view where probably every item signed needs to still
exist unmodified to be presented in its original form for the signature to be
useful.  But I believe there will be plenty of uses, mostly in the protocol
arena, where it will be very common for a recipient to only care about some of
the manifest items, where others that it does care about it already has in local
storage from previous messages so including it will be a waste, where any 2 out
of 3 resources validating are adequate, or only caring if something has changed
or not since it was signed, etc.

Taking a copy could be viewed as an application level task.  However, I
think it would be easier for those who must write a signature manifest if
they could give a URI, but mark it as volatile (e.g. using an attribute).
Then, the algorithm that creates the signature would know to do the
following: 1) obtain the content, 2) store it in a local element within the
document, and 3) change the URI in the manifest to point to the local
element before creating the hash of the manifest.

@@@ Getting the content pointed to by a URI can't be the job of the core
signature module because it is, in general, impossible.  How do you get the
content of <greendreamssleepfuriousy:foobar#987654321>?  The function you
describe would certainly be useful in many cases but I believe it is not a core
signature function.

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

Received on Friday, 23 July 1999 15:16:45 UTC