Re: [dss] Namespace inheritance, other approach

[Trevor Perrin <trevp@trevp.net>]

Martin,

Thanks for your comments.  I think I understand the concern, now, about 
transmitting all "nodes of the underlying parse tree", so further 
transforms can be applied properly on the server-side.  My idea of using 
a special <NamespaceContext> element to transmit some of these nodes 
works for exclusive canonicalization, but this context would be lost for 
other transforms.

Let me try another proposal:
  - Clients have to add any inherited namespace prefixes as attributes 
of the root node of an Input Document or signature.
  - To apply XML transforms, servers must ignore encompassing namespace 
context from the DSS request.  In particular, to apply Canonical XML, 
servers must actually apply Exclusive Canonical XML.  (I'm not sure what 
rules to specify for applying XPath - probably we'll have to disallow 
certain types of XPath expression or something.  I assume we can figure 
this out, and I think server-side XPath will be a rare case anyways, so 
if we have to disallow or add constraints on it, that's OK).

Anyways, how does this sound?


Trevor



Martin Centner wrote:
> 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
>