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

RE: Exclusive Canonicalization: A trivial problem

From: John Boyer <JBoyer@PureEdge.com>
Date: Wed, 20 Jun 2001 14:00:42 -0700
Message-ID: <7874BFCCD289A645B5CE3935769F0B520C33F6@tigger.PureEdge.com>
To: "Joseph M. Reagle Jr." <reagle@w3.org>
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>

Hi Joseph,

Obviously, I agree with being agreed with.  I also agree with prior
emails from Don and Merlin that the algorithm proposed by Don, modified
to have something like an IncludeNS as a catch-all for namespaces which
are in use but cannot be detected by Don's algorithm, can be rigorously
defined in a few paragraphs and is quite easy to implement.

Furthermore, IncludeNS seems to be a satisfactory addition in that it
covers a great fraction of the cases that are likely to occur in
practice.  The only difficulty with IncludeNS is that it puts the onus
partly on the application to come up with the list (extra namespaces
used within SignedInfo can be assessed by xmldsig-core, except those
appearing inside Object elements).  This doesn't seem to add more than
an extra parameter to a signature generation function in a generalized
signature software module.

John Boyer
Senior Product Architect, Software Development
Internet Commerce System (ICS) Team
PureEdge Solutions Inc. 
Trusted Digital Relationships
v: 250-708-8047  f: 250-708-8010
1-888-517-2675   http://www.PureEdge.com <http://www.pureedge.com/>  	

-----Original Message-----
From: Joseph M. Reagle Jr. [mailto:reagle@w3.org]
Sent: Wednesday, June 20, 2001 12:08 PM
To: John Boyer
Cc: Phil Griffin; Phillip Hallam-Baker; Donald E. Eastlake 3rd;
Subject: Re: Exclusive Canonicalization: A trivial problem

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
expression (as parameterized with or without comments) and how to
the resulting node sets. When combined with generic XPath functionality,
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
the Canonical XML purposefully and wisely uses its ancestor context. 
However, this is not always appropriate to the enveloped protocol
That's fine! While we did consider permitting arbitrary XPath transforms
SignedInfo, many people were concerned that such flexibility over that
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
now -- amid concerns about dependencies and timing. And because of
XML's design, this is technically very easy: defining a different 
canonicalization using a slightly different node set selection but
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
>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 17:01:17 UTC

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