RE: [dss] Namespace inheritance, other approach

["Edward Shallow" <ed.shallow@rogers.com>]

Folks,

This wholw tree and sub-tree discussion is fine, and I believe we are
getting closer to consensus. But please remember we still have occassions
where some form of encoding/escaping will always be required (i.e. <?XML
...> declaration lines and PI lines which would precede the root). This is
the "whole document" scenario which we have not outlawed and is a legitimate
use-case. Hence the "encoding=" attribute that we are contemplating that we
borrowed from "ATOM" would have to support, at a minimum 1) xml (the default
perhaps), 2) escaped, and 3) base64.

Cheers,
Ed  

-----Original Message-----
From: Martin Centner [mailto:martin.centner@labs.cio.gv.at] 
Sent: May 18, 2005 10:07 AM
To: dss@lists.oasis-open.org
Cc: Konrad Lanz
Subject: Re: [dss] Namespace inheritance, other approach

Hi Trevor,
Hi everyone,

maybe I can help to explain the issue my colleague Konrad is concerned about
...


If some transforms are applied on the client side and some transforms are
applied on the server side the intermediate result has to be transmitted
from the client to the server. This is trivial if the intermediate results
are octets. However, it gets tricky if the intermediate result is a
node-set.

The node-set to be transmitted is a set of nodes of an underlying parse tree
A. To transmit the node-set it has to be serialized or canonicalized
somehow. If the node-set does not include all nodes of the underlying parse
tree, re-parsing the canonicalized node-set will result in a different parse
tree B. This will likely effect any further transforms applied on the server
side - including canonicalization.

Thus, transmitting an arbitrary node-set from the client side to the server
side is not more than an implicit C14N-transformation. Therefore, this
transformation should be reflected in the list of <ds:Transforms> of the
corresponding <ds:Reference> element. Whether exclusive or inclusive
canonicalization is used does not matter in this case.

However, there are cases where the difference in the two parse-trees A and B
may not be relevant to the subsequent transforms. For example, if the
node-set to be transmitted are the nodes of a complete subtree of A.
   In this case the octets to be transmitted may be obtained by serializing
the corresponding subtree of A. Therefore, in some cases it may not be
necessary for the client to implement C14N and the C14N-transformation may
be omitted from the list of <ds:Transforms>.

Thus, it could be left to the client to take appropriate measures in order
to make the resulting signatures verifiable. However, it may be wise to make
implementers aware of the issue mentioned above.


Kind Regards,
martin


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php