- From: Joseph M. Reagle Jr. <reagle@w3.org>
- Date: Wed, 20 Jun 2001 15:07:53 -0400
- 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 UTC