RE: Tentative signature over C14N examples

Hi Petteri,

Please note the following sentence, which leads the fifth paragraph of
section 2.1:

"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."

Example 3.5 is designed to ensure that implementations conform with this
requirement (so that validating and non-validating processors have the same
output).

Thanks,
John Boyer
PureEdge Solutions Inc.

-----Original Message-----
From: w3c-ietf-xmldsig-request@w3.org
[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Petteri Stenius
Sent: Wednesday, October 11, 2000 5:54 AM
To: 'John Boyer'
Cc: xmldsig-interop@pothole.com; XML DSig
Subject: RE: Tentative signature over C14N examples



Does not the "Entiry References" sample in chapter 3.5 of [1] require a
validating parser because of the external entity references?

The spec does not require a validating parser, should not the sample be
changed to not require a validating parser?

Petteri

[1] http://www.w3.org/TR/2000/WD-xml-c14n-20000907

> -----Original Message-----
> From: John Boyer [mailto:jboyer@PureEdge.com]
> Sent: Friday, October 06, 2000 9:53 PM
> To: merlin@baltimore.ie
> Cc: xmldsig-interop@pothole.com; XML DSig
> Subject: 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 Wednesday, 11 October 2000 11:44:13 UTC