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

RE: AW: AW: ObjectReference shouldn't be signed, was RE: Loca

From: John Boyer <jboyer@uwi.com>
Date: Thu, 11 Nov 1999 14:48:29 -0800
To: "Raghavan Srinivas - Sun Microsystems (by way of \"Joseph M. Reagle Jr.\" <reagle@w3.org>)" <Raghavan.Srinivas@East.Sun.COM>, "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>
Message-ID: <NDBBLAOMJKOFPMBCHJOIMECBCCAA.jboyer@uwi.com>


-----Original Message-----
From: w3c-ietf-xmldsig-request@w3.org
[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Raghavan Srinivas -
Sun Microsystems (by way of "Joseph M. Reagle Jr." <reagle@w3.org>)
Sent: Tuesday, November 09, 1999 7:49 PM
To: IETF/W3C XML-DSig WG
Subject: Re:AW: AW: ObjectReference shouldn't be signed, was RE: Loca


Hi:

Based on the ensuing discussions at the 46th IETF meeting I
tried to reflect on this problem.

There are at least two schools of thought.

1. Since the signature includes the objectreference, changing
   the URL for the reference should render the signature invalid.
   In an example quoted, the signature may probably
   be applicable based on the contents of the URL (for
   example some terms of agreement).

<John>
Signatures of this type are already covered by the spec (just don't omit
anything from the SignedInfo).  The fact that many signatures will benefit
from this is different from asserting that all signatures will benefit.  A
signature without ObjectReferences has no value.  Hence, signing SignedInfo
is an artifact of our design.  The assertion that the data must be at a
location is an extra assertion that may often be useful, and is usually not
harmful, but we already have three scenarios where it is undesirable.
Many who belonged to the above school of thought confused what the user *may
often* require with what is *always* required.
</John>

2. URLs can and will change and the way to override signature
   becoming invalid is to escape the objectreference from
   being included in the signature.

Why not effectively sign for the document and the contents
of the object reference, not the object reference itself?
This should address some of the issues of 1 & 2. i.e.
changing the URL is fine as long as the contents don't
change ...

Does this seem reasonable?
<John>
I don't understand how this suggestion adds anything to what the people in
the second camp are saying.  We, or at least I, believe that this act of
signing SignedInfo (and hence ObjectReference) is an intermediate
calculation that gets in the way of doing what the signer really wants to
do, which is sign the actual content indicated by the ObjectReferences, not
the object references themselves.

Quite some time ago I suggested that we eliminate this two step approach in
favor of simply concatentating the indicated resources together with
selected data from the SignedInfo element, and having the SignatureValue
digest be over the result.  The idea was ignored, either because I write too
much or because the idea was disliked.  The only value I see in the current
method is that it is quite clean in how it applies a single signature to
cover multiple resources.  Unfortunately, the cleanliness only works if I
can use the actual messages that were digested in further work, which the WG
has stated as a non-goal.

Regardless of the utility of the current method, certainly it should not add
artificial assertions to the data that the user actually wants to sign, or
better yet it should only create those assertions if they are required by
the user.

I quite like the idea that most of the time the assertion that the data was
at a specific location must be maintained.  However, I respect the scenarios
given me by members of the community.  Thus, I don't think it is reasonable
to support only the latter school of thought. I would prefer some method of
supporting both needs.

John Boyer
Software Development Manager
UWI.Com -- The Internet Forms Company
</John>

Thanks!

Rags

	Resent-Date: Tue, 9 Nov 1999 11:15:44 -0500 (EST)
	Resent-Message-Id: <199911091615.LAA22897@www19.w3.org>
	From: rhimes@nmcourt.fed.us
	To: <w3c-ietf-xmldsig@w3.org>
	MIME-Version: 1.0
	Content-Transfer-Encoding: 7bit
	Content-Description: "cc:Mail Note Part"
	Subject: Re:AW: AW: ObjectReference shouldn't be signed, was RE: Loca
	Resent-From: w3c-ietf-xmldsig@w3.org
	X-Mailing-List: <w3c-ietf-xmldsig@w3.org> archive/latest/724
	X-Loop: w3c-ietf-xmldsig@w3.org
	Resent-Sender: w3c-ietf-xmldsig-request@w3.org


	>>The simplest example is a changing URL.

	>I know that example, but that happens so rarely that I would consider
it
	>appropriate to resign.

	Peter,

	I don't think we should assume that there is one or a few signers of a
set of
	documents under a URL domain, nor that the signers are readily available
for
	re-signing.  Also, URLs change frequently on the web.  I suspect that
once we
	have proliferation of XML signatures, the problem will be at least as
common.

	Thanks,
	Rich
Received on Thursday, 11 November 1999 17:49:21 GMT

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