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

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

         http://www.w3.org/Signature/Drafts/xmldsig-core/Overview.html
         $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 
intent
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;">
        ...
        </Signature>
    </Contract>

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

    <SOAP-ENV:Envelope
      xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
      ...
      <SOAP-ENV:Body>
        <Contract xmlns="&foo;">
          ...
          <Signature xmlns="&dsig;">
          ...
          </Signature>
        </Contract>
      </SOAP-ENV:Body>
    </SOAP-ENV:Envelope>

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
should:

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

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