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

RE: Poll on Exclusive Canonicalization

From: John Boyer <JBoyer@PureEdge.com>
Date: Mon, 18 Jun 2001 15:45:39 -0700
Message-ID: <7874BFCCD289A645B5CE3935769F0B520C33F2@tigger.PureEdge.com>
To: "Donald E. Eastlake 3rd" <lde008@dma.isg.mot.com>, "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>

Hi Don,

>So, namespaces used by XPath expressions in XPath elements would need
>be declared.  Doesn't seem like a big problem to me.  

Do you have any suggestions here? Would an IncludeNS element content
of exclusive canonicalization algorithm elements which had an
attribute whose values was a list fo prefixs (NMTOKENS) that would be
considered used, even though their prefix did not appear to be used,
do the trick?  So you might have
  <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#excludeC14N">
    <IncludeNS Prefixes="foo bar etc"/>

It seems that, at a minimum, the IncludeNS parameter would be a good
improvement.  I don't see how to avoid referring directly to namespace
prefixes given that they are directly used in such things as XPath

Matters worsen, however, if the XPath (or whatever opaque concoction
appears in an Object) refers to the namespace URI and not the namespace
prefix.  E.g., what if there were an XPath transform that essentially
said include each node if the result of namespace-uri() is equal to
namespace-uri(here()), or some similar expression that queried the
namespace context from which you are trying to make exclusions.

In general, I found this problem quite vexatious in the past because it
would be far easier if we could simply tell whether a namespace node
exists by virtue of inheritance versus redeclaration in the source
document.  If we could do that, then we wouldn't need to worry about
whether something is being used and could have instead simply said that
c14n has a mode whereby it only writes declared namespace nodes.

>Use of exclusionary c14n outside of the limited context of signing
>SignedInfo seems problematic from an implementers standpoint.  What is
>the plan here?

I don't understand your question. As I proposed them, these seem to me
to be well defined algorithms that can operate anywhere inclusive
canonicalization can be used.  What's problematic?

It just seemed that figuring out how to specify what namespaces to keep
would be harder in the general case, regardless of how it was done.
Consider the IncludeNS parameter for an exclusionary c14n of an
externally referenced document.  Aside from the difficulty of
determining which namespaces it actually uses (e.g. the prefixes used in
XPath expressions), it seems you'd have to go get the document just to
find out what namespaces are used in its start tags so you could set up
the IncludeNS parameter, which would need to be done before the core

Then, there's the case of a Reference within the same document, but with
an XPath transform that includes a forest consisting of an arbitrary
number of possibly pruned subtrees of the document.  This seems more
generalized than applying the method to SignedInfo, which is one subtree
with no pruning.  Maybe it isn't so bad, but I just haven't thought
through cases like what happens if the so-called apex node is not in the
node-set or what happens if the intervening node that declares a
namespace is not in the node-set.  Maybe these cases just go through
with the same "Then, you shot yourself in the foot" response.  

Finally, I guess I'm a little concerned about whether the proposed
method of deparenting the apex node is "supposed" to work or if it works
by happenstance in the implementations tried so far.  Has anything been
done to see whether this behavior is something we can count on going

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 Monday, 18 June 2001 18:46:11 UTC

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