W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > October to December 1999

Re:RE: Locations but not Transforms as hints (was RE: The XM

From: <rhimes@nmcourt.fed.us>
Date: Mon, 22 Nov 1999 17:27:56 -0700
Message-Id: <9911229433.AA943316925@nmcourt.fed.us>
To: <w3c-ietf-xmldsig@w3.org>


>1) The transforms over signed info is only one way to solve the scenarios 
>in hand; it just happens to be a good one.

John, could you please explain again why it is better to run transforms (XPaths)
over SignedInfo than to just include the things you want to sign in SignedInfo,
and placing things you don't want to sign outside SignedInfo (but within
Signature, call it UnsignedInfo if you wish.)  Seems like it would be a lot
clearer and cleaner to me.  If it is related to document closure, could you
please show (by examples) how the former preserves and the latter breaks
closure?

>It is easy to see how the security of this suggested rule breaks.  Simply
>consider the actual problem we are trying to solve. When a document is
>internally stored in element E, we must do the following:

>IDREF (or barename XPointer transform) to indicate E
>XPath child::text()
>Base64 decode.

>Since the base 64 decode happens last, all of the transforms are unsigned
>and there are no signed transforms.  Thus, the object can be arbitrarily
>modified in the unsigned transforms with no possibility of reality checks 
>by the signed transforms.  In general, the signed transforms won't be able 
>to run reality checks that secure this method even if they did exist.

>In conclusion, then, arbitrary unsigned transforms are a very, very bad
>idea, leading to precisely the problems *you* identified in prior emails 
>to this group.  If we are going to omit a transform from an 
>ObjectReference, we
>need some digitally signed description of *precisely* what that is so that
>the description can pass a security audit as a non-threat.  This is the
>essence of document closure as applied to SignedInfo itself.

I took another look at the example in question.
Quote:

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

I'm still looking at what you signed, not what was transformed, so it's bad, but
not as bad as it looks at first.  Anyway, I'm still stuck with the optional
base64-decode problem if we must sign all transforms.  I believe we should be
able to move documents to internal (base64-encoded) and multiple external
locations without breaking the signature.  I don't have a strong feeling about
transforms being signed, except that it prevents optional internal
base64-encoding.

Thanks,
Rich
Received on Monday, 22 November 1999 19:28:55 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:08 GMT