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

RE: Locations but not Transforms as hints (was RE: The XML-DSig Non-standard, or Location/Transforms as 'hints')

From: <tgindin@us.ibm.com>
Date: Wed, 24 Nov 1999 18:04:56 -0500
To: "John Boyer" <jboyer@uwi.com>
cc: "DSig Group" <w3c-ietf-xmldsig@w3.org>, "Mark Bartel" <mbartel@thistle.ca>
Message-ID: <85256833.007EC600.00@D51MTA05.pok.ibm.com>
     John, I guess the field names weren't clear enough.  Location would be
assumed to be fixed in all cases, while currentLocation would be treated in
the same way as "location-as-hint" by a verifier (current refers to the
time of signature).  I was just providing separate names for the separate
uses, and trying to make the names illuminate the difference.  It would
make little difference whether currentLocation were signed or not, since
the assertion embodied by the field value is not falsifiable by a later
verifier, and breaking it by moving the reference doesn't imply anything
about breaking the signature.

          Tom Gindin

"John Boyer" <jboyer@uwi.com> on 11/24/99 04:49:07 PM

To:   Tom Gindin/Watson/IBM@IBMUS, "DSig Group" <w3c-ietf-xmldsig@w3.org>
cc:   "Mark Bartel" <mbartel@thistle.ca>
Subject:  RE: Locations but not Transforms as hints (was RE: The XML-DSig
      Non-standard, or Location/Transforms as 'hints')




This is precisely my point. It's a problem because our design forces the
signing of something that either prevents core from solving a class of
problems or requires core to depend on application specific location
resolution using the URI as a hint.

The currentLocation field does not contribute anything, it just moves the
same omission argument to a different attribute.

Regardless, the point is that if we could omit location from the
SignedInfo,
then the Location is free to be changed to the value desired.  It should be
noted, though, that there is a second (I would argue more important) class
of problems that MUST have the location signed, so the trick is whether we
can get core behavior to be configurable (omit  if told to omit, or don't
omit by default).
(snip)

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


-----Original Message-----
From: tgindin@us.ibm.com [mailto:tgindin@us.ibm.com]
Sent: Wednesday, November 24, 1999 1:32 PM
To: John Boyer
Cc: Mark Bartel
Subject: RE: Locations but not Transforms as hints (was RE: The XML-DSig
Non-standard, or Location/Transforms as 'hints')


     If location were unsigned, location-as-hint would not be a "brutal
hack" - it could be redefined as follows: "Location: the value of this
field is the URI at which the resource was located when the signature was
created".  It is only a hack because we are making the signer sign it, and
then saying "don't take this too seriously".
     For that matter, if we had two different names whose use was mutually
exclusive, "Location" and "currentLocation", and "currentLocation" was
omitted from the signature base when present, there wouldn't be much of a
hack either.

          Tom Gindin
Received on Wednesday, 24 November 1999 18:05:10 GMT

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