Re: AW: signature portability / C14N / inherited namespaces

Hi,

From:  "Gregor Karlinger" <gregor.karlinger@iaik.at>
To:  "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>
Cc:  <w3c-ietf-xmldsig@w3.org>
Date:  Thu, 31 May 2001 17:49:13 +0200
Message-ID:  <LBEPJAONIMDADHFHAEAOCEDFCGAA.gregor.karlinger@iaik.at>
In-Reply-To:  <200105311356.JAA0000032048@torque.pothole.com>

>Donald,
>
>> Gregor,
>>
>> We need to fix this problem somehow. If we are going to stop inherited
>> namespaces from flowing down into signed material, whether it is
>> signed XML data or SignedInfo, but those namespace declarations are
>> still needed, then we need to do something to be sure they are still
>> there.
>
>In case of signed XML data, I think there is no reason to stop inherited
>namespaces form flowing down; an approach to deal with namespaces that
>are declared in an ancestor, but are not used in the considered XML
>document subset, has been shown by John Boyer [1]:
>
>One could add an XPath Transform prior to the C14n Transform, that removes
>all superfluous namespace nodes from the original XPath node set.

I think it will be a complex and brittle arrangement to burden most
application developers with the task of always knowing all of the
namespaces needed within any signed XML and constructing an XPath
expression to delete all others from all elements in this signed XML.
Whenever due to a change in their applciation or in XML data being
carried along, the needed set of namespaces changes, then the
application has to change its XPath expression. Besides that, they
have to do the same for other xml namespace attributes, like
xml:lang. Besides that, they have to do it for SignedInfo and in that
case we need additional rules to carefully constrain the XPath
transform of SignedInfo because it is very dangerous.

Instead of all this complexity, why not handle the normal case, of
only wanting the namespaces which are used, by a mode of
Canonicalization?

>> Sticking with the current C14N but cutting out the part to be
>> canonicalized with DOM or something before it is canonicalized, I
>> would have said we would need to also tell people to explicitly
>> declare any needed namespaces in the data, at the apex of the piece of
>> XML to be canonicalized, not in the Transform.
>
>In case of SignedInfo we cannot go this way since SignedInfo cannot be
>manipulated by a Transform prior to calculating its canonical
>representation.
>
>If we cut out the SignedInfo from its context and rather treat it as the
>document element of a virtual document, then we run into the problem that
>some descending elements of SignedInfo could need some of the lost namespace
>declarations. To solve this problem, the namespace declarations must be
>made explicitely somewhere down the descendant axis of SignedInfo:

You are making assumptions about this cutting. Assuming that XML can
be cut like the piece of paper it is printed on seems not to be the
case for many of the developers implementing XML Security. I gather
most use DOM and/or XPath models. For the "cutting" to help. it had
better be DOM, because it is currently inconsistent with XPath and
does not flood namespace declarations down the tree.  But it sounds
like future versions of DOM may very well do that.  If people are
implementing with DOM and DOMs start acting more like XPath, then this
"cutting" will not work unless you define the "cutting" to work at
character level or the like, something which several implementers have
told us is very hard.

>  - in the SignedInfo element itself (as you are in favour of)
>
>  - in those descending elements of SignedInfo that can be filled with
>    arbitrary content: either CanonicalizationMethod, SignatureMethod,
>    DigestMethod or Transform (this was my original suggestion when I
>    was talking about Transform)
>
>  - anywhere in the arbitrary content of the elements cited above (i. e.
>    when the ns declaration is needed for the first time, for instance
>    in the XPath element of the XPath Transform element).

Sure, if you can actually do this cutting, which I have serious doubts
about because it seems to either (1) drag in DOM which may only work
temporarily or (2) require reference to the character level which has
proven hard to impelment, then you have to tell people to fix up any
missing namespaces due to the cutting by adding them back someplace
where they work in the cut out part.

Wouldn't it be easier, for the 99% of the cases where it works, to
just specify a Canonicalization function that doesn't gratuitously
import xml namespace attributes and strips unused namespace
declarations?

Donald

>[1]
>http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001AprJun/0151.html
>
>Liebe Gruesse/Regards,
>---------------------------------------------------------------
>DI Gregor Karlinger
>mailto:gregor.karlinger@iaik.at
>http://www.iaik.at
>Phone +43 316 873 5541
>Institute for Applied Information Processing and Communications
>Austria
>---------------------------------------------------------------
>
>
>> From:  "Gregor Karlinger" <gregor.karlinger@iaik.at>
>> To:  "merlin" <merlin@baltimore.ie>,
>>             "Gregor Karlinger" <gregor.karlinger@iaik.at>
>> Cc:  <w3c-ietf-xmldsig@w3.org>
>> Date:  Thu, 31 May 2001 09:21:24 +0200
>> Message-ID:  <LBEPJAONIMDADHFHAEAOGECNCGAA.gregor.karlinger@iaik.at>
>> In-Reply-To:  <20010524121300.46F9044C71@yog-sothoth.ie.baltimore.com>
>>
>> >Merlin,
>> >
>> >> Hi Gregor,
>> >>
>> >> r/gregor.karlinger@iaik.at/2001.05.24/14:08:19
>> >> >  I have not thought a lot about the consequences of the
>> following idea,
>> >> >  but anyway: Should we add an additional rule both to the processing
>> >> >  rules for signature generation and validation, that the SignedInfo
>> >> >  element should be isolated from its context prior to computing
>> >> >  the canonicalized representation?
>> >>
>> >> Unfortunately we can't isolate SignedInfo. An XPath/XSLT Transform
>> >> can legitimately rely on inherited namespaces. I have a queued
>> >> followup to my earlier question on this topic, I just need to
>> >> finish it.
>> >>
>> >> Merlin
>> >
>> >Yes, some transforms could rely on inherited namespaces. But if we change
>> >the processing model slightly, we can cope with this problem: Simply
>> >state that all namespaces that are used in a transform MUST be declared
>> >in the Transform element.
>> >
>> >Liebe Gruesse/Regards,
>> >---------------------------------------------------------------
>> >DI Gregor Karlinger
>> >mailto:gregor.karlinger@iaik.at
>> >http://www.iaik.at
>> >Phone +43 316 873 5541
>> >Institute for Applied Information Processing and Communications
>> >Austria
>> >---------------------------------------------------------------

Received on Monday, 4 June 2001 00:29:16 UTC