- From: Donald E. Eastlake 3rd <lde008@dma.isg.mot.com>
- Date: Wed, 06 Jun 2001 17:11:41 -0400
- 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