RE: Exclusive Canonicalization: A trivial problem

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;
w3c-ietf-xmldsig@w3.org
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
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 17:01:17 UTC