RE: Omitting Location and Transforms from SignedInfo

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

Actually, my example didn't require the original signer to be negligent,
only for one of the currently approved signature methods to be broken.

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 Saturday, 13 November 1999 23:12:49 UTC