W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > October to December 1999

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

From: <rhimes@nmcourt.fed.us>
Date: Mon, 08 Nov 1999 17:20:08 -0700
Message-Id: <9911089421.AA942106935@nmcourt.fed.us>
To: <w3c-ietf-xmldsig@w3.org>
Cc: <aschmidt@darmstadt.gmd.de>, <reiner.huettl@munich.ixos.de>, <robert.frost@munich.ixos.de>, <connolly@w3.org>, <liberte@w3.org>
Joseph Reagle wrote:

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

Aren't we causing the problem that is "not ours to solve" by freezing these
values that will likely change?  I suspect that moving stuff out of the digest
calculation isn't too much of a headache, but I admit that it would change the
structure.  We could also exclude (/include) these values using attributes or
another transform.  Another possibility is to specify these values (location and
transforms) at the same level we specify other attributes (e.g. date-time
signed) and optionally include them as objects.

>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''

I think this would be appropriate in some contexts where we need the detailed
audit trail of location changes, and it would be a nice option.  It may be a bad
example, but (an example I just e-mailed, sorry for the dup) suppose I manage a
site with signed RDF statements about the documents on my site and I "dumbly"
used URLs to refer to them.  Gigacorp buys my company and changes the domain to
www.gigacorp.com.  I'd prefer to just correct the references than to add
thousands of RDF statements correcting each reference.  Also, in my court filing
example where I am moving a document (base 64 PDF) from a delivery envelope to a
native PDF, I don't want the clutter (the standard needs to be less intrusive
IMO.)

Thanks,
Rich
Received on Monday, 8 November 1999 19:21:53 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:08 GMT