RE: Omitting Location and Transforms from SignedInfo

Hi John,

Jim wrote:
>>As my previous mail has stated.  Location is a hint for where the document
>>is.  It is not the be-all and end-all for locating the document.  If the
>>application wants to enforce that this is the only location -- that is
fine.
>>If the application wants to say that the data is someplace else -- that is
>>fine.  The fact that you update the document at a URL location will not
>>allow you to repudiate the fact that you signed the document.  I can cache
>>the document locally and take that copy into court when attempting to
>>enforce your signature.

You replied:
>It's not a hint right now!  How is core behavior, independent of
>application-specific behavior, going to validate a given signature if it
>does not know how to dereference a location.  It cannot depend on
>application specific caching mechanisms.

Um, location is most definitely a *hint* right now; there is nothing in the
core behavior that requires de-referencing a location URI, hitting the
network and sucking down bits.  To quote from the
http://www.w3.org/Signature/Drafts/WD-xmldsig-core-19991116.html draft,
Section 6.2 step 1 reads:

	1. locate object and apply Transforms to the specified resource
based on each 	ObjectReference(s) in the SignedInfo element. Each transform
is applied in order 	from left to right to the object with the output of
each transform being the 	input to the next. 

Do you believe that "locate" here implies always de-referencing a Location
pointer and downloading bits?  I certainly do not believe that is the case.
My application may have any number of methods of binding URIs to objects and
resolving those bindings.  And, of course, I'm fully within my rights as an
application to completely ignore the location URI if I happen to have an
alternative handle on the object.

The impression I get from your messages is that you believe changing the
location of a signed object somehow invalidates the signature on that
object.  I strongly disagree with this notion; in fact I cannot see how the
location of blob of signed bits has anything (in general) to do with the
signed statements about that blob of bits.  The location is *not*
semantically significant to the signature (well, you could certainly define
an application domain in which was true, but I can't think of a single
situation in which that would be useful or meaningful).  In fact, I'd hate
to think that a signature on an object is invalid because I do not happen to
understand the particular protocol used in a Location URI.

Can you explain why you think that the location of an object is somehow
semantically relevant to the signature on that object?  What sort of
semantics are you trying to express?  And how do you expect such semantics
to interact with common Web elements such as caching servers, proxies,
redirects, insecure DNS and unauthenticated HTTP GET methods (e.g. all the
various ways in which it is perfectly legal and useful to spoof location)?

					--bal

Received on Wednesday, 17 November 1999 21:52:58 UTC