RE: XPath transform

Hi Kent,

1) Including the containing elements of the attributes does not guarantee
that the result will be well-formed.  To be well-formed, there must be a
single element at the root.  If an XPath includes all attributes with the
name "Id", then whether or not the element containing that attribute is
included, the result is likely to be a list of elements, not a single
element.  Thus, C14N still cannot be applied to the result if we only make
the restriction that attributes must be accompanied by their parent
elements.

2) I was not attempting "arrogation" in defining the behavior of XSLT
implementations.  I asked you a question, which you didn't answer.  The
question was:  For any XPath expression E that yields a node-set which
includes attributes, what is the character result of the XPath expression
string(E) under your given XSLT implementation?  More importantly, whether
the XPath people like it or not, it is a bug in their specification when two
applications that follow the "specification" yield different results for
string(E).  It is not arrogance to point out that because a specification
has a bug in it, not all compliant software will be usable.  Procrustean
perhaps, but not arrogant.

3) Don Eastlake and I discussed this problem at the FTF.  I believe we
agreed that applying C14N afterward would solve the problem provided we made
more severe restrictions on the output of the XPath.  In other words, we
will apply c14n to the result of the expression, and if the c14n algorithm
chokes because the XPath output is not well-formed, then the signature is
broken. (He did not want it to be quite that severe, but see Note 1 below).

Reasons:  a) The intent of the Xpath transform is to allow a certain amount
of filtering out of unwanted elements, but the cases we have a problem with
are filtering out so much information that the document is no longer
well-formed.  b) XPath transforms are quite unlikely to be written by
amateurs; in most application scenarios I can envision, each XPath transform
will be crafted to the document containing it, and both the document and the
transform will be certified for use.

Note 1: If the result of a given XPath is a node-set containing multiple
elements, it is possible for the XPath author to modify E such that the
output is a well-formed document (if for no other reason than because it is
possible to do string concatenation in XPath).

Note 2: The implication of your feedback is that c14n preprocessing will NOT
solve the problem of attribute order during the Xpath expression evaluation.
Thus, expressions that use the Position() function on the attribute axis
(for example) have undefined meaning.  This is another manifestation of the
XPath specification bug as far as I'm concerned.  Don and I also discussed
this and both felt that we should simply recommend against such expressions.

Note 3:  Despite not solving the attribute order problem, the c14n
preprocessing is still useful for the following reasons:  a) By using c14n,
we at least guarantee that the encoding is UTF-8, so we will not need to
figure out a way to affix a byte order to the XPath output (if the output
were UTF-16, then the c14n algorithm would need this).  b) Attribute value
normalizations are done in a consistent way. c) We reap all of the benefits
of the minimal canonicalization.

4) Questions.

a) Would you agree that we should use c14n post-processing even though this
constrains XPath results more than you may have previously believed?  If so,
it is most likely that it will be changed.

b) Would you agree that it is sufficient for us to simply recommend against
use of Xpath functions that rely on an order for the attribute axis?

c) Would you agree that we should retain the c14n preprocessing for the
reasons I described above?

Thanks,
John Boyer
Software Development Manager
UWI.Com -- The Internet Forms Company

> Secondly, based on what you've said, I don't understand how attribute
order
> translates into a problem.  It does not seem likely that 'string(some
> XPath)' could produce a set of elements with their associated attributes
in
> the desired order, yet 'string(some XPath/attribute::node())' might
scramble
> the attributes from the desired order.  Thus, if you cannot solve the
> attribute order problem with your XPath implementation, then you have a
> problem whether or not the attributes' containing elements are included in
> the XPath.

If the elements with some attributes are included in the result
of XPath, we can apply the XML-C14N transform after the
XPath transform.  We have a problem in the case where the result
is not well-formed.

If the result of an XPath transform was always well-formed, we
could calculate a digest value by applying the XML-C14N
transform. Otherwise, the XML-Signature specification must
define octet stream presentations for the result of XPath, not
string representations.

> In general, the dsig xpath transform should be implemented so that its
> behavior is equivalent to applying c14n as preprocessing then reading the
> result and maintaining its document order as node-set transformations
occur.
> There are few things that could be simpler.  If LotusXSL or XT don't
support
> this ability, then a new XPath implementation will be required.  You
cannot
> use an existing XPath implementation if it is not sufficiently robust to
> support how dsig is applying XPath.

One of the advantege of using XML and XML-related specifications
is that we can reuse existing implementations conforming to each
specification.

It seems arrogation that the XML-Signature specification defines
behavior of XSLT implementations.


--
TAMURA Kent @ Tokyo Research Laboratory, IBM

Received on Monday, 24 January 2000 13:03:46 UTC