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

Re: Exclusive Canonicalization: A trivial problem

From: Joseph M. Reagle Jr. <reagle@w3.org>
Date: Wed, 20 Jun 2001 15:07:53 -0400
Message-Id: <4.3.2.7.2.20010620144954.00b8b858@localhost>
To: "John Boyer" <JBoyer@PureEdge.com>
Cc: "Phil Griffin" <phil.griffin@asn-1.com>, "Phillip Hallam-Baker" <pbaker@verisign.com>, "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>, <w3c-ietf-xmldsig@w3.org>

John, I agree that any characterizations of Canonical XML as broken are 
incorrect. Canonical XML does two things and does them well: it decides 
which nodes of a parsed XML (in the XPath data model) via its default XPath 
expression (as parameterized with or without comments) and how to serialize 
the resulting node sets. When combined with generic XPath functionality, it 
can serialize anything! <smile/>

I've often said there is no single "The Canonical XML" because different 
applications will need different things. In it's default XPath expression, 
the Canonical XML purposefully and wisely uses its ancestor context. 
However, this is not always appropriate to the enveloped protocol scenario. 
That's fine! While we did consider permitting arbitrary XPath transforms on 
SignedInfo, many people were concerned that such flexibility over that data 
was too much, and instead, we would rely upon the careful specification 
of  standardized canonicalization algorithms (instead of user specified 
XPaths) that have a well specified data-model/node-section and 
serialization. Canonical XML 1.0 is one such algorithm that's made it to 
REC, but there could be others. And this is exactly what we are considering 
now -- amid concerns about dependencies and timing. And because of Canonical 
XML's design, this is technically very easy: defining a different 
canonicalization using a slightly different node set selection but exactly 
the same serialization method!

At 14:42 6/20/2001, John Boyer wrote:
>Suppose we add an XPath element to the Signature element as a sibling of
>SignedInfo.  The XPath would say how to filter the SignedInfo.  The
>processing model would then say:
>
>1) Form a node-set consisting of the entire subtree rooted at
>SignedInfo, including namespace and attribute nodes.
>
>2) Apply the XPath expression.
>
>3) Add the subtree rooted by the XPath element in Signature, including
>attributes and namespaces.
>
>4) Send resultant node-set to C14N.
>
>5) Sign result.
>
>End of story.  Full stop to conflict.  Thanks for coming out.


--
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, 20 June 2001 15:08:21 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:13 GMT