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

Hi Rich,

I got your subsequent email about getting the Mark Bartel example.  I am
assuming that this means you don't need me to answer this anymore given that
the ability to break Mark's transform application rule with your scenario is
also quoted by you below.  Can you please write if you want me to do more?

For what it's worth, I agree that you should be able to move documents from
within a document to the outside without breaking the signature.  One
solution was a guaranteed-to-be-signed xpath transform of SignedInfo.
Another was to put some things outside of SignedInfo, but I've posted
reasons why that doesn't work.  A third 'solution' is to say that core
behavior should not be encumbered by the problem of finding resources that
are outside of the current document.  This is still a solution because
*your* application can do it using a manifest.  It's just that only your
application will be able to authenticate the data that your application
signed.  How is this different than 'location as hint'? It gets the
application specific behavior out of the core behavior.  Core is self
contained.  It doesn't do as much, but what it does is tight, smaller,
well-defined, and gets rid of that dratted XSLT transform.

Anyway, I'm in a 50-50 split over options 1 and 3.  I like 1 because it
solves more problems with core behavior; I like 3 because it is tight,
smaller, well-defined, etc.  Still, the WG may well do neither...

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







-----Original Message-----
From: w3c-ietf-xmldsig-request@w3.org
[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of
rhimes@nmcourt.fed.us
Sent: Monday, November 22, 1999 4:28 PM
To: w3c-ietf-xmldsig@w3.org
Subject: Re:RE: Locations but not Transforms as hints (was RE: The XM




>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 20:16:18 UTC