Re: initial Exclusive Canonicalization draft

Hi Donald,

Looks good. A couple of points:

1) I think that namespace-qualifying the XPath expressions might be
useful:

   ancestor-or-self::n1:elem1

2) I'm not sure that your definition of pertinence is ideal:

  <bar xmlns:a="foo">
    <baz xmlns:a="oof">
      <a:b xmlns:a="foo">

I think that the first xmlns:a should be impertinent. Do we need language
expressing the fact that the namespace node must be visibly used by an
element in the document subtree and the namespace prefix must not be
alternatively defined betwen the declaration and this use (whether or
not the alternative definition is in the node set is irrelevant).

3) We might need to add a note to the XMLDSIG spec under the XSLT
section that if a signature which incorporates an XSLT transform is
subsequently enveloped in a document that adds additional namespace
definitions, then those namespace definitions will be output by the
XSLT unless each namespace prefix is explicitly disallowed with
exclude-result-prefixes which is not, of course, generally possible. 
I think that this is true, anyway. Basically, I think that the c14n
namespace problem applies to XSLT.

The text in [http://www.w3.org/TR/xslt.html] is: "The created element
node will also have a copy of the namespace nodes that were present on
the element node in the stylesheet tree [...]".. I'm not sure where
"present on" is exactly defined, but at least one processor interprets
it as equivalent to the XPath namespace axis.

4) I disagree with the specification "a comma separated list of namespace
prefixes". That is an implementation detail. I think this should be simply
"a set of namespace prefixes which may include a token representing use
of the default namespace". Or something like that. By all means, we may
specify a comma-separated list for the XML encoding of this parameter. But
not here. In xmldsig-more. In that encoding, the empty list "" should be
interpreted as only the default namespace, whereas the absence of a list
should be interpreted as no unsuppressed prefixes. Alternatively we could
use the XSLT formulation; whitespace-separated prefixes, with '#default'
meaning the default namspace.

I have yet to fully peruse your possible method of implementation.

I've tweaked my exclusive c14n to attempt to conform with your draft.
Attached is a sample signature with its c14n. I've used the algorithm
identifier http://www.w3.org/2001/04/xmldsig-more#minimal-c14n
and an optional element UnsuppressedNamespacePrefixList (namespace
http://www.w3.org/2001/04/xmldsig-more#) with character content (the list,
may be empty).

This is a Higgs boson release, so may be far from the truth. And it's not
a very good example; it doesn't show xml:foo noninheritance, etc. When
I have time I'll try a better example.

Following along that train of thought, in
http://www.ietf.org/internet-drafts/draft-eastlake-xmldsig-uri-01.txt,
the identifier for XPointer is .../xptr - I think it should
be ...#xptr and I think the namespace for the XPointer element
(and any other element or attribute defined in &more;) could be
http://www.w3.org/2001/04/xmldsig-more# to be consistent with &dsig;.

Merlin

r/dee3@torque.pothole.com/2001.07.09/12:28:50
>
>An initial draft of an Exclusive Canonicalization recommendation is
>now available at
><http://www.w3.org/Signature/Drafts/xml-exc-c14n>.
>
>Comments welcome.
>
>Thanks,
>Donald
>
>=====================================================================
> Donald E. Eastlake 3rd                      dee3@torque.pothole.com
> 155 Beaver Street                                +1 508-634-2066(h)
> Milford, MA 01757 USA                            +1 508-261-5434(w)
>


-----------------------------------------------------------------------------
Baltimore Technologies plc will not be liable for direct,  special,  indirect 
or consequential  damages  arising  from  alteration of  the contents of this
message by a third party or as a result of any virus being passed on.

In addition, certain Marketing collateral may be added from time to time to
promote Baltimore Technologies products, services, Global e-Security or
appearance at trade shows and conferences.

This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.
   http://www.baltimore.com