- From: John Boyer <jboyer@uwi.com>
- Date: Tue, 11 Jan 2000 10:15:10 -0800
- To: <Gregor.Karlinger@iaik.at>
- Cc: "DSig Group" <w3c-ietf-xmldsig@w3.org>
Hi Gregor, I didn't realize that this problem was also in section 2.3. This is a much more direct undermining of the transforms than appears in the previous sections (6.2.2 and 7.1) that I cited before in [1]. [1] http://www.w3.org/TR/2000/WD-xmldsig-core-20000104/ Obviously I don't agree and think section 2.3 should also be changed. For starters, I recall the end of the 'location as hint' discussion occuring when I provided a manifest/transform method for omitting locations such that it was not necessary to do location as hint. The location as hint discussion came up because someone wanted to move the data after it was signed. I don't recall the end of the conversation being that we would adopt location as hint. The reason I don't agree with this idea is that it is so easy to make the resulting signature system look foolishly lame. Consider the following scenario. Developer builds software application A that includes this notion of verifier obtaining URI contents from a local cache. Security Analyst tests A as follows: On client machine, receive document containing signature S over content defined by URI. On client machine, verify signature S, which causes content of URI to land in local cache. Go to web server and modify content at URI. On client machine, verify signature S. S verifies after content has been changed. Result: Security analyst assigns failing mark to A since changing the content doesn't break the signature. Caching data is a great idea for overcoming minor connection-time glitches over the web when the content doesn't really matter. But the content really, really matters a lot when it comes to signatures. It shouldn't be possible to trip up a signature in such an absurdly simple scenario. At most, we could have an implementation note stating that applications could obtain the results by means other than digging up the URI content and doing the IDREF. The note should say that we recommend against this approach for security reasons (such as described above), but it may be of value to do this in certain limited contexts (??). I can also see this notion of caching being restricted to obtaining content from URIs. Whereas, my comments were more about the importance of doing the *transforms*. As I recall, the intent of the statements in Section 2.3 were trying to communicate the idea that an application may have a cached copy of the data with some of the transforms already done. Such an application could feel free to just apply the remaining transforms. I actually don't see this as very likely, but regardless the SPECIFICATION SHOULD HOLD APPLICATIONS ACCOUNTABLE FOR THE SIGNED STATEMENTS ABOUT THE DIGESTED MESSAGE. The paragraph you cite in section 2.3 says "In particular, the data may be in a different location". Perhaps the intent of the paragraph was only to provide for caching of URIs and IDREFs more so than undermining the utility of XPath transforms. In my opinion, the paragraph should read "This identification, along with the transforms, are a description provided by the signer on how to obtain the signed resource in the form it was digested (i.e. the digested content). The verifier (i.e., relying party) may obtain the starting content from a different location than the specified URI/IDREF (such as a local cache), but the derived content message MUST be the result of applying the transforms to the starting content. Editor's Note: Caching content poses a security risk and should be avoided when possible." John Boyer Software Development Manager UWI.Com -- The Internet Forms Company -----Original Message----- From: w3c-ietf-xmldsig-request@w3.org [mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Gregor Karlinger Sent: Tuesday, January 11, 2000 7:48 AM To: John Boyer Cc: DSig Group Subject: Re: Transforms useless in current spec John Boyer wrote: ... > Presumably, there is great emphasis on the word 'may'. The word should be > MUST, and the paragraph in Section 7.1 should be removed. Otherwise, you > should take the transforms out since they are useless. 6.2.2 should read: > > 6.2.2 Reference Validation > For each object reference in SignedInfo, obtain digested content (this MUST > be obtained by locating object and applying Transforms to the specified > resource based on each Reference(s) in the SignedInfo element. Each > transform is applied in order from left to right to the object with the > output of each transform being the input to the next.). I disagree with that. Please remember the discussion a few weeks ago concerning "location as a hint". The result of that discussion can be found for instance in the following paragraph of section 2.3 of [1]: "This identification, along with the transforms, are a description provided by the signer on how to obtain the signed resource in the form it was digested (i.e. the digested content). The verifier (i.e., relying party) may obtain the digested content in another method so long as the digest verifies. In particular, the verifier may obtain the content from a different location (particularly a local store) other than that specified in the URI/IDREF." [1] http://www.w3.org/TR/2000/WD-xmldsig-core-20000104/ -- --------------------------------------------------------------- Gregor Karlinger mailto://gregor.karlinger@iaik.at Institute for Applied Information Processing and Communications Austria ---------------------------------------------------------------
Received on Tuesday, 11 January 2000 13:18:51 UTC