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

Proposal: Text for signature portability / C14N / inherited namespaces, etc.

From: Joseph M. Reagle Jr. <reagle@w3.org>
Date: Wed, 06 Jun 2001 13:39:56 -0400
Message-Id: <>
To: "Donald Eastlake" <dee3@torque.pothole.com>, <lde008@dma.isg.mot.com>
Cc: "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>, Hugo Haas <hugo@w3.org>, plh@w3.org

My stab at some text for the spec on this note follows:

         $Revision: 1.67 $ on $Date: 2001/06/06 17:31:42 $

7.3 Namespace Context and Portable Signatures

In the [DOM], [XPath] and consequently [XML-C14N] data models an element has
namespace nodes that correspond to those declarations within the element and
its ancestors:

     "Note: An element E has namespace nodes that represent its namespace
     declarations as well as any namespace declarations made by its ancestors
     that have not been overridden in E's declarations, the default 
namespace if
     it is non-empty, and the declaration of the prefix xml." [XML-C14N]

When serializing a Signature element that's the child of other elements using
these data models, that Signature element, and/or its children, may contain
namespace declarations from its ancestor context. This may frustrate the 
of the signer to create a signature in one context which remains valid in
another. For example, given an enveloped signature in a contract:
    <Contract xmlns="&foo;">
        <Signature xmlns="&dsig;">

when the contract is moved into a [SOAP] envelope for transport:

        <Contract xmlns="&foo;">
          <Signature xmlns="&dsig;">

The canonical form of the signature in this context will contain new namespace
declarations from the envelope context, invalidating the signature.
Applications that wish to create enveloped signatures that survive portage

  1. Rely upon the enveloping application to properly divorce its body (the
     signature payload) from the context (the envelope) before the signature 
  2. Use a canonicalization method that "repels" instead of "attracts" 
     context. [XML-C14N] purposefully attracts such context; the alternative 
     not yet been defined, (though it is an easy task), and this specification
     will not make any implementation or conformance requirements over such a

Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/
Received on Wednesday, 6 June 2001 13:40:25 UTC

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