Re: Omitting Location and Transforms from SignedInfo

I find your arguments persuasive, so I'm reversing my position on signed
transforms.

In your reply to Mack Hicks, you state that "the signature should be applied
to a format of the document as close as possible to the presentation
format."  I like this idea, and I'm starting to think that maybe transforms
have been trying to do things backwards (or maybe it's just my reading of
them that is backwards).

Instead of saying "do A, B and C to this document before verifying the
signature" perhaps transforms should just indicate the "base format" that the
document was in when it was signed.

Admittedly, I'm not exactly sure how this could be done (MIME types,
maybe?).  But it seems to me that the problem with transforms is that the
signer has to make assumptions about how the verifier will obtain the signed
content.  Things might be easier if the signer could just state what format
the content was in when it was signed.

		Marc


rhimes@nmcourt.fed.us wrote:
> 
> >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 16:37:08 UTC