Proposal RE: Poll: Relative URIs and Strings in xmlns attributes

Hi all,

Earlier this week, I sent a private email to Joseph indicating that I was
only in favor of choice #2 if applications were not REQUIRED to support
relative namespace URIs, but rather required to either generate an error or
support them as strings.  Under such a construction, signatures over XML
with non-absolute URIs in namespaces would not necessarily interoperate, but
at least the only two possibilities for interoperation would be success or a
failure with 'deprecated or unsupported feature' (rather than 'message
tampered with').

In the absence of this choice, my vote would have to be for choice #1.  In
short, I think it is more important for us to be forward looking than
backward compatible. To elaborate, I think that future XML processors
available to create the XPath node-set (or functionally sufficient
alternative) consumed by C14N will come in three flavors:

1) those that follow the deprecated thinking and automatically absolutize
namespace URIs
2) those that retain knowledge of the original namespace name, even if it is
a relative URI (these may also provide the absolute URI, but the important
feature is that the original string is at least available to be placed in
the canonical form)
3) those that adhere to the plenary decision and throw an exception when
they encounter a non-absolute URI in a namespace name

NOTE: In my opinion we should not specify the behavior as simply undefined
and say that signatures over XML containing relative namespace URIs may not
interoperate.  The reason is that the interoperation failures actually come
across as tampered message errors, which can lead some to make incorrect
conclusions and take incorrect actions long before the processes of reason
and deep technical analyses can kick in.

Now we examine each of the two choices under each of the three processors:

Choice #1
=========
1) These MUST NOT be used to create an implementation of C14N since the
serialization phase of C14N will not be able to determine that the document
was altered from its original form.  This requirement poses no difficulties
because the implementer can easily determine the characteristics of a given
processor before using it.

2) These are capable of providing the original string; it is, therefore,
easy to apply the rules of RFC2396 to detect and throw an exception if the
namespace name is not an absolute URI.  SUCCESS!

3) These automatically throw an exception if a non-absolute namespace URI is
encountered.  SUCCESS!

Choice #2
=========
1) These MUST NOT be used to create an implementation of C14N since the
serialization phase of C14N will not be able to determine that the document
was altered from its original form.  So, the resulting canonical form will
be incorrect without our ability to specify how to detect otherwise.

2) These are capable of providing the original string. SUCCESS!

3) These MUST NOT be used because they automatically throw an exception if a
non-absolute namespace URI is encountered, which would be non-conformant
behavior under choice #2.

As you can see, given my note on the importance of generating the right
error when a signature validation fails, neither of the choices permit C14N
to be created with a processor that absolutizes namespace URIs, and both
choices can be supported by a processor that makes the original namespace
name string available to the c14n implementation.

However, the selection of choice #2 means that future implementers of c14n
are unable to use XML processors that conform to the plenary's
recommendation.  On the other hand Choice #1 can be supported by quite a
number of currently available processors (type 2), as well as future
processors that adhere to the plenary's recommendation.

Therefore, it seems reasonable to propose that we go with Choice #1 as it is
specified above, i.e. REQUIRE implementers to A) not use Type 1 processors,
B) generate errors if Type 2 processor used and non-absolute namespace URI
found, or C) use a Type 3 processor.

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 Thursday, 21 September 2000 19:23:15 UTC