Re[2]: Omitting Location and Transforms from SignedInfo

>I _really_ think the last option is the right direction:

Agreed.

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

I favor transforms being outside SignedInfo (see below).

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

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

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

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

Thanks,
Rich

Received on Wednesday, 17 November 1999 13:17:59 UTC