W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > January to March 2000

RE: Transforms useless in current spec

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

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

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

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

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
   (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
   as a local cache), but the derived content message MUST be the result of
   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
> 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
"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
   by the signer on how to obtain the signed resource in the form it was
   (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
Institute for Applied Information Processing and Communications
Received on Tuesday, 11 January 2000 13:18:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:33 UTC