C14N: Non-absolutized URIs

Hello all,

Firstly, thanks to Brian LaMacchia [1] for earlier notification that this
was coming, and thanks to Lauren Wood [2] for reiterating this issue.

[1]
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JulSep/0342.html
[2]
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JulSep/0459.html

Looks as if there will soon be errata issued to several W3C specs (including
XPath) to reflect the resolution sent to this group by Dan Connolly [3],
which states that relative namespace URIs are not to be interpreted.  This
will percolate into XPath in the form of a statement that the behavior of
relative namespace URIs is application dependent.

[3]
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JulSep/0465.html

To the extent that C14N is an application of XPath (in its current
formulation), C14N is therefore free to say that relative namespace URIs
MUST NOT be converted to absolute URIs.

To the extent that this would be a very good turn of events for
XML-Signature, I hereby propose the following:

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

2) I will modify C14N to include a specific example showing the invariance
of a relative URI under canonicalization (I'll probably just add it to one
of the existing examples rather than adding a section just for that).

3) I will modify C14N to include an extra section in Chapter 4 explaining
the rationale for this change.  The rationale is very similar to namespace
prefix rewriting, namely that it can break things that used to work or make
things work that used to break.

Finally, note that this email is a written record of an outcome from a
teleconference today (11 September 2000) with Dan Connolly and Joseph Reagle
in which Dan agreed that a second last call of C14N should not be necessary
based on this change.  The rationale is that Candidate Rec is a time for
implementations to begin, so prior implementers should still be at an
advantage if they must make this change (esp. given that most had to do some
work to make absolutizing happen in the first place.

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.

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

Thanks,
John Boyer
Development Team Leader,
Distributed Processing and XML
PureEdge Solutions Inc.
Creating Binding E-Commerce
v: 250-479-8334, ext. 143  f: 250-479-3772
1-888-517-2675   http://www.PureEdge.com <http://www.pureedge.com/>

Received on Monday, 11 September 2000 17:35:49 UTC