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

Re:AW: Re[2]: Omitting Location and Transforms from SignedIn

From: <rhimes@nmcourt.fed.us>
Date: Wed, 17 Nov 1999 15:24:40 -0700
Message-Id: <9911189429.AA942936151@nmcourt.fed.us>
To: <Peter.Lipp@iaik.at>, <w3c-ietf-xmldsig@w3.org>, <jboyer@uwi.com>, <gwhitehead@signio.com>

>> It really concerns me that there is so little concern about
>> locating objects.
>I strongly believe don't think finding an object has anything todo with
>digital signatures. I am still waiting for somebody giving a real life
>example where you have the signature, and the signature only, and go off
>searching for the corresponding data. The other way, having the data and
>looking for a signature, might be more appropriate, but in that case any
>unique id is fine (so I really liked Josephs suggestion to use the hash).

We are allowing the signed object to be internal or external to a document.  Are
you disagreeing with this?  Should the object always be imbedded in the
<Signature> element?  If not, don't you have to locate it?  What if the signed
object isn't XML and isn't embedded?  Are you assuming we go for the object
first instead of the XML document that refers to it?  Are you trying to enforce
this approach?  Are you accounting for huge complex multi-departmental data
storage or reference sites?

I could envision applications where documents talk about other remote documents,
or at least we should allow for it.  Suppose I make a statement that "The
document at www.xxx.com/PG is suitable reading for children".  I could just sign
that statement and be done with it, but then I start worrying that a hacker
might go to that site and change it to pornographic content.  To make sure, I
could sign the document and say "I assure that the document at www.xxx.com/PG is
suitable reading for children if it can be authenticated with this (my)
signature" (the document hasn't changed since I read it).



Received on Thursday, 18 November 1999 09:42:59 UTC

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