RE: Re[2]: Omitting Location and Transforms from SignedInfo

Hi Rich,

>I would suggest moving the transforms inside the signature, though.

I favor transforms being outside SignedInfo (see below).

<John>
If the ObjectReference transforms are not covered by SignatureValue, then
one cannot achieve document closure.  Please see my letter to Don.
</John>

>The issue I see with signing the transforms is that some might interpret
>that to mean the transformation must be blindly applied.  This needn't be
>the case, at least not for all transforms.  base64 encoding is a good
>example here.  It's easy to tell whether something is in base64.  If it
>isn't, don't try to base64-decode it!  This basically makes the transforms
>optional.  In the limit, you can theoretically wind up with a set of
>transforms, every combination of which may need to be tried on the object
>before its digest matches the signed digest.  In practice, I doubt that
>there will ever be (a) a large set of transforms (i.e. > 2) and (b) a set
>of transforms so baroque that the right combination has to be discovered
>through an exhaustive search.

But if the transforms are outside SignedInfo, the exhaustive search is
unnecessary.  I think this is too much to expect for cross-vendor solutions
to
give us a consistent answer.  Also, if we have a lot of objects, the number
of
combinations grows rapidly.

If we have a transform which says "if and only if the document is base64
encoded, decode it", I believe we should have a standard way of identifying
the
state of the document as base64-encoded (outside SignedInfo).  Otherwise, I
believe transforms belong outside SignedInfo, and the transform should be
just
"base64-decode".

<John>
We should not get into optional transforms, esp. since base 64 is, so far,
the only transform that should not produce an error if the data is not in
base64.  For example, what should happen if an XPath is applied to non XML?.
I think the XML processor errors should halt the validation.

Furthermore, I do not agree that it would *always* be easy to determine that
a document is base64 encoded.
For example, a document in raw form could begin with a sequence of
characters that are indistinguishable from base64 encoding.  So, how far do
you go?  Then, theoretically at least, the entire message could be raw but
use only base 64 characters.  To wit, this sentence is base64 except for the
spaces and punctuation.
</John>

>Now the question might arise: If the transforms are optional, why sign
>them at all?  The reason is to restrict the possible set of
>transformations. While in the end the signer doesn't really have any
>control over the verifiying software, by signing the transforms at least
>the signer gets to say "If you do anything other than one of these things
>to the object, then you accept my signature at your own risk."  The issue
>is that you want to prevent some evil transform from creating an object
>that has a falsely matching digest.

<John>
The above is precisely the document closure argument.  Some time ago I gave
a reasonably complete XFDL example that should be in the archives.  Send me
an email if you have questions about it.
</John>

This problem has been hinted at, but I really don't understand it.  We could
just as easily have a false location to a bad document which spoofs the
signature.  If there are signed transforms, all we have to do is run the
reverse
of the transforms on the spoof document.  If you can create such a document
with
the transforms you mention, we should just as easily be able to create this
document with signed transforms (run the spoof transforms, run the reverse
signed transforms, then point to the new document.)

<John>
First, I think you're running transforms too many times.  Second, you can
point to a spoof document, but is the spoof document signed with the private
key of the original signer?
</John>

If creating a meaningful spoof document (with or without transforms) that
doesn't break the signature is relatively easy, then digital signatures seem
worthless.

<John>
The spoof document still has to validate with the private key of the
original signer.  The original signer signed a bucket of bytes.  If you can
recover the original bucket of bytes, who cares how you did it?

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

Thanks,
Rich

Received on Wednesday, 17 November 1999 17:32:51 UTC