- From: Joseph M. Reagle Jr. <reagle@w3.org>
- Date: Fri, 01 Jun 2001 17:21:43 -0400
- To: Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com>
- Cc: "'xml-encryption@w3.org'" <xml-encryption@w3.org>, "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>, Hugo Haas <hugo@w3.org>, plh@w3.org
I've been muddling about this too and my summary and opinion of the situation follows: At 12:23 5/30/2001, Eastlake III Donald-LDE008 wrote: >In some sense, in the Encryption use case I describe above, you want C14N >to "attract" the context. But for portable XMLDSIG, you normally want to >"repel" the context. Good, this is a nice way to describe it. Given the scenario: a signature when placed in an XML "envelope" will attract and exhibit the ancestors' namespace declarations in its canonical form, breaking the signature. The options we seem to have available to us are: 1. Leave it to the application. In response to Merlin's question about DOM [1], Philippe Le Hégaret confirmed that removeChild will divorce the child from its ancestor namespace declarations. 2. Define a new canonicalization method that repels ancestor context. [2] 3. Permit SignedInfo to be transformed. [1] http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001AprJun/0149.html [2] http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001AprJun/0208.html [3] http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001AprJun/0218.html The options above are actually listed in order of my preference, but I've covered all the bases, right? The reasons for my preference is as follows (in reverse order): 3. Big change, and scary as before. 2. I generally like this idea, and a "repelling" c14n might be a useful document regardless, but: 1. I spoke to Hugo Has about this in the XML Protocol context and he informally said his expectation of XMLP processors would be that they do their business and "detach" their payloads and hand them off to other modules (like dsig) anyway. If this is the case, writing an XPath expression to remove your from your wrapped context could actually get you confused. For example, if envelope specific XPath expressions are written that only survive in SOAP but not other envelopes. This might be a red herring as I'm sure one could write a generic intend-to-be-enveloped XPath expression. Regardless, it doesn't seem very modular. Let applications that carry around XML after the signature worry about the encapsulation and detachment, those specs can best address this problem. >As for cutting up the document with DOM before applying C14N, I am >reluctant to drag in another data model and require DOM as well as some >part of XPath for simple normal uses of C14N to support XML Digital Signature. I don't think it's a DOM data model issue. I just think it's the enveloping applications concern of how it processes it's payloads, and some text of warning in the dsig spec is advisable, but that's all I'm presently advocating. >PS: Since C14N currently suppresses declarations of the xml namespace to be >its standard value, should it also suppress declarations of xmlns to be >"http://www.w3.org/2000/xmlns/" which the DOM group has decided should be >its standard value? I'm not sure if you're saying it should suppress those, or present that as the value? Regardless, the DOM WG hasn't decided anything on this note. This value is not in the Infoset or DOM data model, it's just available to implementations: http://www.w3.org/2000/xmlns/ >But in some processing contexts, e.g. DOM, it is useful to represent all >XML attributes as (namespace name, local name) pairs. For this purpose, the >namespace name http://www.w3.org/2000/xmlns/ is assigned. -- 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 Friday, 1 June 2001 17:21:52 UTC