RE: Tentative signature over C14N examples

Hi Merlin,

Note that your message did not go to the DSig list.

<merlin>
<snip/>
Note that I do not concur with the spec for example 4: I don't
understand the subtlety of marking the attribute as an ID; my
nonvalidating parser treats it no differently.
</merlin>

<john>
Yes, your non-validating parser should have no trouble with the id attribute
of normId.  A validating parser, however, should get a little choked up
about the ID attribute because the attribute should conform to NmToken but
doesn't.
I also notice that your example 4 did not strip out the leading and trailing
whitespace for that attribute's value.  The example in c14n-20000907 is
wrong for not doing that.
By saying that your non-validating parser treats it no differently, are you
saying that your non-validating processor does not realize that the
attribute is identified as an ID attribute?
If so, please see Section 5.1 of the XML specification regarding conformance
of non-validating processors.

Though not applicable to this example, please also note the following from
Section 2.1 of C14N:
"The input octet stream MUST contain a well-formed XML document, but the
input need not be validated. However, the attribute value normalization and
entity reference resolution MUST be performed in accordance with the
behaviors of a validating XML processor."
This requirement means that a non-validating processor can be used, but the
c14n implementation is required to augment the processor by reading the
external DTD subset for the additional declarations.
</john>

<merlin>
Neither do I concur with the spec for example 7: I do not see
a justification for xmlns="".
</merlin>

<john>
The justification is that e3 is not namespace qualified in the input, so it
should not be namespace qualified in the output.  The problem is that,
unfortunately, the XPath data model represents an empty default namespace
with the absence of a node, not with the presence of a default namespace
node having an empty value.  Thus, w.r.t. e3, we cannot tell the difference
between <e2 xmlns=""><e3/></e2> versus <e2><e3 xmlns=""/></e2>.  All we know
is that e3 was not be namespace qualified on input, so we preserve this
information on output.
</john>

<merlin>
I tweaked the XPath on example 7 to suit signature processing.
</merlin>

<john>
Perhaps you could provide the full XPath transform that you've used.  I'm
pretty sure your tweak is fine, but I'd like to see the declaration of the
ieft prefix.  BTW, is there some reason why you didn't use the subexpression
inside the square brackets of example 7?
</john>

<merlin>
John, I presume that xml:foo attributes are sorted using the
standard value for xmlns:xml if none else is specified?
</merlin>

<john>
Yes.  The default value for the xml prefix provides the namespace URI that
functions as the primary key of attributes beginning with the xml: prefix.
</john>

<merlin>
Also, the NOTATION needs a SYSTEM.
</merlin>

<john>
Yikes! I will fix that immediately.
Canonical form is unaffected-- unfortunately :(
</john>

Merlin

Received on Friday, 6 October 2000 14:53:50 UTC