- From: John Boyer <jboyer@uwi.com>
- Date: Wed, 24 Nov 1999 13:49:07 -0800
- To: <tgindin@us.ibm.com>, "DSig Group" <w3c-ietf-xmldsig@w3.org>
- Cc: "Mark Bartel" <mbartel@thistle.ca>
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