Exclusive Canonicalization: A trivial problem

HERE IS A REPEAT FOR THOSE WHO DON'T DO HTML IN EMAILS, WHICH I'M FORCED
TO DO THANKS TO A BUG IN THE LATEST MICROSOFT EXCHANGE SERVER.


As you may have guessed from my prior email "RE: Poll on Exclusive
Canonicalization", there remains a simple design tweak to XMLDSig that
A) would not hold up anything pertaining to status of the XML DSig spec,
B) should be trivial to implement and test for interoperability, and C)
solves more problems than just the namespace issue.

I mention this technique in part to help everyone understand that the
current conflict is not arising from a shortcoming in C14N but rather in
XML DSig's application of C14N and/or the application of XML DSig in a
particular scenario (signing SOAP messages).  

Consider the following sentence from the C14N Spec "Since XML
canonicalization converts an XPath node-set into a canonical form, the
first parameter MUST either be an XPath node-set or ..."

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.

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/>

Received on Wednesday, 20 June 2001 14:43:09 UTC