OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]