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

RE: Omitting Location and Transforms from SignedInfo

From: Greg Whitehead <gwhitehead@signio.com>
Date: Wed, 17 Nov 1999 18:13:07 -0800
Message-ID: <6B962A1EE646D31193270008C7A4BAB5381EB9@mail.paymentnet.com>
To: "'John Boyer'" <jboyer@uwi.com>, DSig Group <w3c-ietf-xmldsig@w3.org>
Sorry, "clumsy" was a poor choice of words.

My point is that using transforms over SignedInfo to solve the object
location problem, when we would have to come along and protect against 99%
of what a transform might do, is just making a lot of work for ourselves.

> The SignedInfo transforms would serve as a precise description of what got
> omitted.  If too much of ObjectReference gets omitted, then the digital
> signature is thrown out as worthless.  But if the SignedInfo transforms
omit
> only transforms of type base-64, then document closure and overall
security
> are preserved.

This kind of post-mortem analysis, after a SignedInfo is transformed, is
exactly what I don't want to end up having to specify or implement.

> The other reason I suggested doing this by transforms is that it seemed
> unclean from an engineering standpoint to create a second method to omit
> Location and certain transforms when we already have a method.

I'm not in favor of omitting location or transforms from object references,
period.

I've explained my viewpoint on location, that I believe it is properly an
application-level problem, and I'm afraid to think about the need to omit
"certain" transforms. This sounds like another slippery slope.

If the goal is just to handle the fact that a base-64 encoded object might
be cached on disk in binary format, why not just put some simple logic in
the transform engine to automatically transform the encoding returned by the
object fetcher into an encoding specified in the object reference (I think
we would need to add this property):

1) the object fetcher returns an object's (current) encoding along with the
object
2) the object reference indicates the object's encoding (when signed)
3) the transform engine knows how to do/undo base-64 encoding to get from
"current" to "when signed"
4) optionally, the transform engine knows how to optimize away a
back-to-back base-64 encode/decode or decode/encode

So, if you cache a base-64 encoded object on disk in binary form, and the
object's reference in the signature has a base-64 decode as the first
transform, the transform engine just skips ahead to the second transform.

-Greg

-----Original Message-----
From: John Boyer [mailto:jboyer@uwi.com]
Sent: Wednesday, November 17, 1999 4:59 PM
To: Greg Whitehead; DSig Group
Subject: RE: Omitting Location and Transforms from SignedInfo


Hi Greg,

Sorry, but it's not a "clumsy" solution to suggest that A) transforms can go
on SignedInfo but B) there must be some restrictions.

I suggested transforms on SignedInfo not because I wanted to be crucified
but because I wanted to be very specific about which transforms can be
omitted.  Read Mark Bartel's recent post on the dangers inherent in allowing
some ObjectReference transforms to be omitted.

The SignedInfo transforms would serve as a precise description of what got
omitted.  If too much of ObjectReference gets omitted, then the digital
signature is thrown out as worthless.  But if the SignedInfo transforms omit
only transforms of type base-64, then document closure and overall security
are preserved.

The other reason I suggested doing this by transforms is that it seemed
unclean from an engineering standpoint to create a second method to omit
Location and certain transforms when we already have a method.

Finally, it may be quite possible to slightly tweak the markup design so
that these "clumsy" security exceptions don't even exist.  That's why it's
not a good idea to use such characterizations too quickly.

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



Hi John,

The question isn't so much whether transforms are signed or not, but what
they're allowed to do. I have to admit a certain ignorance of the
capabilities of the transforms proposed for inclusion in the initial version
of the spec, but I'm assuming that once Pandora's box is opened anything is
possible.

The bottom line is that any transform over SignedInfo with the ability to
modify itself (along with some other critical piece of information like
SignatureMethod or the DigestValue or Transforms in an ObjectReference) is
open to abuse. Given all of the restrictions that must be placed on
transforms over SignedInfo in the name of security, it seems like a clumsy
solution to the original problem.

I'm not discounting the original problem -- I just prefer a solution that
passes the object location problem off to the application. Even in the case
of URLs pointing to resources that haven't moved, an application verifying
the signature on an object probably has other uses for the object itself
(and should probably verify the signature against the version of the object
that it fetches, rather than a version that the signature verification core
fetches independently).

-Greg


-----Original Message-----
From: John Boyer [mailto:jboyer@uwi.com]
Sent: Wednesday, November 17, 1999 2:30 PM
To: Greg Whitehead; DSig Group
Subject: RE: Omitting Location and Transforms from SignedInfo


Hi Greg,

I apologize for the delay; I've had a lot of work to overcome recently.

I almost agree with your entire analysis.

Basically, in order to hijack the signature, it seems that you would have to
create a SignedInfo transform that omits itself as well as does the
interesting things you described.  By contrast, I rather assumed that we
would create a bottom turtle (to borrow one of Rohit's favorite phrases, and
also to follow the irony that the problem comes from self-reference, a
favorite of Russell's).

By bottom turtle I mean that SignedInfo should include its Transforms in its
text to be hashed even if the Transforms say to omit themselves.  I faced
this problem two years ago in XFDL, and the solution was to disregard the
filters if they tried to filter themselves out of the message to be
digested.  Actually, we do have a larger problem now because of that awful
XSLT transform.  I only want the transforms for the xpath transform because
I only want keep/omit abilities on the given markup, not the ability to turn
it into Mohawk.

Anyway, my point is that I agree with your analysis as given, but the
problem is the result of differing assumptions.  I assume that the
SignedInfo transforms are automatically covered by the SignatureValue and
hence are not modifiable.  Under that assumption, the security problem
vanishes before it gets started.

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



<Greg/>

Forget that, however, and consider this!

You sign object x without specifying any transform over SignedInfo (the
signature includes all SignedInfo elements):

	<Signature>
	<SignedInfo>
	...
	<ObjectReference location="x">
	...
	<DigestValue>xxx</DigestValue>
	</ObjectReference>
	</SignedInfo>
	...
	</Signature>

I modify your signature to refer to object y and I introduce a transform
that undoes this change (restores the original contents of the SignedInfo):

	<Signature>
	<SignedInfo>
	<Transforms>
	<Transform>
	replace SignedInfo with original contents
	</Transform>
	</Transforms>
	...
	<ObjectReference location="y">
	...
	<DigestValue>yyy</DigestValue>
	</ObjectReference>
	</SignedInfo>

As I understand the proposed verification logic, I have now hijacked your
signature. Specifically, we will first go find object y and verify that its
digest is yyy. We will then apply the transformation to SignedInfo, which
will restore it to what you originally signed. We will then verify your
signature of the transformed SignedInfo, which will succeed (implying that
you signed y).

You can't solve this problem by suggesting that verification of digest
values should take place after the transformations are applied, since you
are proposing to drop information like location.

Getting back to the need to drop location at all, your objection to
application specific object location logic is that it can't be cleanly
integrated with the core signature verification mechanism.  I don't buy
that.  It's a lot cleaner to use a callback to locate objects than to rely
on re-writing the ObjectReferences within the signature.

-Greg

-----Original Message-----
From: John Boyer [mailto:jboyer@uwi.com]
Sent: Friday, November 12, 1999 10:05 AM
To: Greg Whitehead; DSig Group
Subject: RE: Omitting Location and Transforms from SignedInfo


Hi Greg,

This is not the only concrete example.  If you go back to the letter I sent
(or indeed my IETF presentation conclusion) you will find that it is not
only possible for transforms to reduce security but also to obliterate it
entirely.  Rather than omitting the SignatureMethod, simply omit the
DigestValue from ObjectReferences, which disconnects the signer from the
signed.

Still, no application is going to create such signatures precisely because
they will make such newsworthy fodder for the Bruce Schneier types of the
world.

Essentially, signing SignedInfo is an implied ObjectReference.  Whatever
fears we have about omission from SignedInfo are precisely the same fears
for omission from referenced objects.  It is a dangerous but necessary
feature (and yes I can explain why (again) in painstaking detail for those
who require it, or you could just come to heckle my presentation of the
material at RSA2000).

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

I just thought of a concrete example:

SignatureMethod is included in SignedInfo to protect against a downgrade
attack, should one of the currently approved signature methods be broken.

Allowing arbitrary transformation of SignedInfo could potentially defeat
this protection by allowing an attacker to introduce a transformation that
substitutes in a broken SignatureMethod along with a reference to a modified
object and other changes (exploiting the broken signature method to produce
the original SignatureValue over the modified SignedInfo).

-Greg
Received on Wednesday, 17 November 1999 21:13:08 GMT

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