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

<John>
Hi Mark,
</John>

It seems to me that the basic issue here is that we're using Transforms for
two things:

1.  To refine the definition of what is being signed in the document
2.  To assist in retrieving the document in the appropriate form

An example of the first is using XSLT (or XPath) to define which part of a
given document the signature is over; an example of the second is base64
decoding.

It is critical that the first type of transform be signed.  It seems equally
critical that the latter type not be signed if the location is to not be
signed, since different locations fairly naturally will have different
encoding.

<John>
I agree here. Signing the XPath type transforms allows one to achieve
'document closure'.
This is part of why I liked the ability to apply a transform to signed info.
One could
then select precisely which transforms should be omitted.  I would like to
omit
transforms that call for base64, but keep the rest.  This would allow those
who
want to change Location and base64 encoding to still accomplish document
closure.
</John>

At first I was thinking, well, why don't we just put all transforms outside
SignedInfo?  You can't actually tamper with what is signed anyway, that is
the entire point of digest algorithms.  But particularly with XSLT the
possibilities for misrepresentation are vast.

For example, I might sign a document declaring that green is my favorite
colour.  Mallory (my unscrupulous interior decorator) might create a
contract that say I agree to pay him $100,000 for services rendered, and
then write XSLT to transform that document into my assertion of colour
preference.  Place that XSLT in a Transform outside of SignedInfo and the
signature will happily verify.  Now, I doubt it would stand up in court, but
I don't want to have to go to court.  In automated business-to-business
scenarios this would be particularly frightening, because the transactions
might not be put in front of human eyes.

<John>
This is a great example of why leaving out ObjectReference transforms can
cause troubles unless we can be very specific about the nature of the
transforms that got omitted.  I.e. yes a transform was left out, but it MUST
have been a base 64 transform because we add all others to the SignedInfo
digest message.
</John>

Proposal 1:
* allow Transforms both inside and outside SignedInfo
* allow Location either inside or outside SignedInfo
* specify that applications are to limit Transforms outside of SignedInfo to
the set of algorithms that they trust

I don’t like this.  I think it is complicated, and there is bound to be
either trust or interoperability problems with the "set of algorithms that
they trust" part.

<John>
I don't either
</John>

Proposal 2:
* Transforms are in SignedInfo
* Location is in SignedInfo
* view Location only as a hint
* applications can use non-signature information to find the object and
transform it into something appropriate to feed into the Transforms

<John>
This part I don't like because it means that every signature is
application-specific and noone can validate anyone else's signatures.
Everyone needs that application-specific plugin that tells how to
dereference the Location.  Yuck!
</John>

Received on Wednesday, 17 November 1999 19:48:44 UTC