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

Finally, I would also put yet another reminder in place that the full
problem is not as simple as fixing just Location.  Just to solve Rich Himes'
scenario, we also need to omit some transforms.  However, we cannot omit
ObjectReference transforms in a secure manner unless we can precisely define
which transforms are omitted such that arbitrary changes to the
ObjectReference's transforms are not allowed.  We already have such a
precise language, and it's called XPath.  Hence, the conclusion I came to at
FTF#3 that we should allow a signed XPath transform on SignedInfo.

Such a transform will not be permitted to omit itself from the SignedInfo
(we lose security without a 'bottom turtle').  Other than that, it is
possible for a security auditor to approve any document for use within an
application context based solely on an examination of the given XPath
filters and on the application processing rules.

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 16:50:33 UTC