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

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

From: <rhimes@nmcourt.fed.us>
Date: Mon, 08 Nov 1999 16:41:42 -0700
Message-Id: <9911089421.AA942104564@nmcourt.fed.us>
To: <w3c-ietf-xmldsig@w3.org>

>>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
>>ObjectReference, for example.

>Not sure I understand that completely, so forgive me if I'm wrong. But 
>while the location of the data does not change the digest value of the 
>object to be signed, the transform does, so there is no way of changing 
>transform without the need for changing the signature. 

The source data is formatted in two different ways.  Thus, the transforms must
be different to come up with the same hash.  The case I was concerned about
involves a PDF (for example) that is first embedded in the document (for
transmission) and then placed in a file.  In the first case, the transform would
be a base64 decode, and the second case would have no transform.  The resulting
transform output in both cases would be the raw PDF, but with different
locations and "transforms".

>I don't see a real case where the location would change and I still would
>need the same signature (containing the location) verify. Can I be in
>posession of a document and unable to find a signature with that specific
>location in? 

The simplest example is a changing URL.  It is common to encounter a web page
that has been renamed, perhaps because another company bought this one out
(changing domain.)  I could even see this happening with URNs (for political or
other reasons, perhaps sloppiness) but it isn't as likely.  Suppose I have a
site that has signed RDF statements about documents on my own site and I decide
to change the base location.  Surely problems such as this will be common.

Received on Monday, 8 November 1999 18:42:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:32 UTC