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 08:52:04 UTC