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

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

From: Donald E. Eastlake 3rd <lde008@dma.isg.mot.com>
Date: Wed, 06 Jun 2001 17:11:41 -0400
Message-Id: <200106062111.RAA25997@noah.dma.isg.mot.com>
To: "Joseph M. Reagle Jr." <reagle@w3.org>
cc: "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>, Hugo Haas <hugo@w3.org>, plh@w3.or

It seems to me that this use of "envelope" is not consistent with the
current use.  We currently call a signature eveloped if one of the
items signed is an ancestor elelemnt of the signature.  But that has
nothing to do with this problem. A signature that signed only binary
remote data will be equally broken if it is moved from one XML context
to another so that new namespace/prefix pairs invade its integrity on
canonicalization.

The wording talks only of divorcing the signed XML from its context on
validation but it is an equally important consideration on
generation. The removal of old context can break things just as badly
as adding new context.  In fact, for signatures to interoperate, the
generator and validator have to somehow agree on this. Otherwise, the
divorcing from context by the validator but not the generator can
break a signature even if the "envelope" hasn't
changed. Interoperability would be easier if this was explicitly
specified.

Donald

From:  "Joseph M. Reagle Jr." <reagle@w3.org>
Message-Id:  <4.3.2.7.2.20010606133149.00b93c30@localhost>
Date:  Wed, 06 Jun 2001 13:39:56 -0400
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
In-Reply-To:  <4.3.2.7.2.20010601161301.02f9f620@localhost>
References:  <1DE737930E15D511B64400D0B76FE2620C0C48@ma07exm01.corp.isg. mot.com>

>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 17:11:54 UTC

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