RE: C14N: Non-absolutized URIs

> -----Original Message-----
> From: John Boyer [mailto:jboyer@PureEdge.com]

> 1) I will modify C14N to state that "Relative namespace URIs 
> MUST NOT be
> converted to absolute URIs, and that the string stored for 
> the namespace
> node value MUST be equal to the character content appearing 
> in the input
> (i.e. the string result of the usual XML 1.0 processing, 
> including entity
> reference resolution and attribute value normalization)."
>
> It is essential that a single behavior be defined for C14N, 
> and the fact
> that XPath permits application-dependent behavior means that 
> applications
> (such as C14N) are permitted to define the most appropriate behavior.
> Retaining the 'raw value' is most appropriate for C14N, esp. for the
> purposes of DSig.

No, the fact that XPath permits application-dependent behavior means only
that the plenary has forced it (along with all other groups) to accept
application-depedent behavior.

> It would be helpful to have brief emails from those 'for' as 
> well as those
> with concerns.

I'm concerned.  It looks like you are defining it a certain way - to be
"literal".  If W3C groups are free to do this, then why don't we just drop
the plan for the XPath erratum and kill two birds with one stone?  I'm
surprised to hear that Dan Connolly agreed to this.

I agree that you are in a tough spot.  I think a clever solution might be
found to work around (not change) XPath's undefined behavior (like retaining
the "literal" value and using this in the serialization algorithm), but I
can only imagine how to do this for c14n.  I don't think you'll be so lucky
with DSig as a whole, as the erratum also affects XPath filtering, and XSLT
transformations.

The XPath Filtering section of DSig [1] states:

  The XPath transform establishes the following evaluation 
  context...  The set of namespace declarations in scope for 
  the XPath expression.

The XPath expression context uses these to compare against namespace
declarations in the source document.  Either or both of the DSig document
and the source document may contain relative namespace URIs.  The results of
comparing nodes under these conditions will be implementation specific.
Thus a signature containing an XPath filter may fail when moved across
implementations.

A similar problem arises with XSLT transforms, which also inherit
implementation-specific behavior from XPath.

[1] http://www.w3.org/TR/xmldsig-core/#sec-XPath

Received on Monday, 11 September 2000 18:42:53 UTC