W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > April to June 2001

RE: AW: signature portability / C14N / inherited namespaces

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

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

> 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

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:

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


Liebe Gruesse/Regards,
DI Gregor Karlinger
Phone +43 316 873 5541
Institute for Applied Information Processing and Communications

> 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 Thursday, 31 May 2001 11:49:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:10:05 UTC