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

Re: signature portability / C14N / inherited namespaces, etc.

From: Joseph M. Reagle Jr. <reagle@w3.org>
Date: Fri, 01 Jun 2001 17:21:43 -0400
Message-Id: <>
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 

>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 

>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

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