Re: ObjectReference shouldn't be signed, was RE: Location

In response to:

http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/1999OctDec/thread.html#2
46

At 12:25 99/11/08 -0700, rhimes@nmcourt.fed.us wrote:
 >We "must" sign the digest method and digest value (and type?) but I
believe it
 >should not be a requirement for location or transforms to be signed.  

We are not signing resources nor their URLs, we are signing a resource's
content that is "shown" when the URL (location) is dereferenced. To that
end, the DigestValue acts as the best location indepedent URI (identifier)
one could ask for. Consequently, this seems like a reasonable thing to do.
(But ...)

 >Some
 >applications may require these to be signed, so it should be an option.
Seems to
 >me that logically, ObjectReference refers to Object which in turn should
allow
 >the data format and location to vary without breaking the signature.  It is
 >precisely the same data semantically, and that is what we should be
signing (a
 >type of canonicalization). Forcing applications to freeze the location
will be a
 >huge problem in the long run, IMO, even if it isn't a URL.  Likewise,
freezing
 >the transform will be a problem for the longevity of the signature in some
 >cases.  (I just realized that allowing location to change helps resolve
the ID
 >conflict when documents are merged.)

However, it seems to me that we might be adding a fair amount of headache to
our specification to address a problem that is not ours to solve. I'm of
mixed feelings on the topic, but we are not tasked with designing ways of
referencing things in a "location indepedent globally unique, persistent"
manner.

 >One way to do this is for the Transforms element of ObjectReference to
specify a
 >transform on Object (rather than it's content), to allow exclusion of a
 >location/transform within Object (transform is not currently specified in
 >object).  I'd like this to be more natural though, by adding an attribute
to
 >ObjectReference, for example.

You mean an exclude attribute? I'd prefer we remain consistent on that
point. Regardless ...

Consider an alternative in the "assertion about assertions" school of
philosophy. (I touched on some of these issues before in [2]). Since an
ObjectReference is merely a set of assertions, someone can make an assertion
that the content yielded from a new {URI,transforms) is the same as that of
an old one.

ObjectReference asserts the following:

Y.a ObjectReference with Identifier/Location "http://1" yields content
Y.b content when Transformed yields content'
Y.c content' when DigestMethod'd yields DigestValue

IF the nature of Y changes then anyone else can make a new statement and
sign that (and you can trust that based on your evaluation of that person's
trust-worthiness.)

Z.a ObjectReference with Identifier/Location "http://2" yields content''
Z.b content==content''

[2] http://www.w3.org/Signature/Drafts/xml-dsig-design-resources-990723.html


_________________________________________________________
Joseph Reagle Jr.   
Policy Analyst           mailto:reagle@w3.org
XML-Signature Co-Chair   http://www.w3.org/People/Reagle/

Received on Monday, 8 November 1999 16:39:38 UTC