Re: [dss] Core spec: client-side transforms, etc.

[Konrad Lanz <Konrad.Lanz@labs.cio.gv.at>]

Dear Trevor and all,

Trevor Perrin schrieb:

> [...]
> It seems we're disallowing clients from applying client-side transforms.

That is correct for the core, with the exception of doing the complete 
transformation including hashing at the client side.

The rational behind this is not to call something a Document that 
actually is a node-set or an OctetStream.

The main question one has to ask is how to transmit/serialize and parse 
a Node-Set, and this is not yet specified and should be done in a profile.

  (e.g. an intermediate Transform Result that is comprised of attribute 
nodes, element nodes and others in the following order
       ns1:attib1=value1
       attib2=value2
       ns2:attib1=value3
       ns2:attib1=value3
       <element1 />
       <element2>  <element3 /> <![CDATA[ns1:attib1=value1 attib2=value2 
ns2:attib1=value3 ns2:attib1=value3 <element1 /> <element2> <element3 
/>]]> </element2>

   and still you would have to fix the issue around the different 
namespace scopes of these nodes to be transmitted.
  )

The next question is how to transmit/serialize octet data embedded in 
XML. It looks easy in the first place, but be wary we are not supposed 
to loose a single bit as we are signing these things. (e.g. 5 clientside 
transformations resulting in an Octet stream and then server side hashing).

ByteOrderMarks, LitteEndianess, BigEndianess, Encoding issues, 
xml-declarations, inconsistent encoding used by the client etc...
If we are lucky the client will handle all these right and finally 
encode it properly in Base64, but what if EscapedXML or even InlineXML 
(formerly XMLData) is used.

Even at the end of the day we would have blown up the core to get all 
these issues right, a DocumentFragment is not necessarily a XMLDocument, 
a NodeSet is not necessarily a XMLDocument and an OctetStream is not 
necessarily a XMLDocument and hence not parseable by an xml parser to be 
parsed to DOM Nodes to be processed by further 
Transforms/Canonicalizations or beeing embedded into ds:Objects or as 
you suggest to be analyzed for it's structure.

> Are we also disallowing clients from sending "Input Documents" which 
> are fragments of larger XML documents?

Yes, see above.

> Is the goal of these changes to simplify/enable application of 
> server-side transforms?

Both.

> As I recall, the most important server-side transform, 
> canonicalization, can easily be made to work with client-side 
> transforms (including extraction of fragments) as long as clients send 
> all relevant namespace context (i.e., clients add inherited namespace 
> prefixes as attributes of the root node of an Input Document) [1].

Correct, this is true for a subset.
There exists a myriad of combinations of complex XPointer References 
which in turn are either part of a same-document reference or external 
references which have to be dereferenced, plus canonicalization, plus 
XPath transformations, plus XSLT-Transformations,
plus custom transformations.

However this subset is at least from my point of view very hard to 
define and it's exact definition will blow up the core considerably.

It is probably not as hard to define a too restrictive subset that will 
work in any case, however this will restrict the core considerably and 
potentially to much for other profiles.

Hence an IntermediateTransform result was suggested in 
http://www.oasis-open.org/apps/org/workgroup/dss/email/archives/200506/msg00018.html 
to move these complex issues to a profile to be established in the future.

> So I presume the rationale for the above changes is that more complex 
> server-side transforms might require XML document context which is not 
> present in a transformed or extracted Input Document.  This was a 
> problem with the core spec as of wd-30.  In hindsight, I think it 
> could be solved one of two ways:
>   A) Limit the server-side transforms the server can apply as part of 
> basic processing

One can doubt that there is an easy way to express how to limit 
server-side transforms in a way which is explicit enough to be enforceable
and wide enough to be too restrictive.
Further this will blow up the core and restrict many transforms from 
being applicable.

My doubts are fostered by the myriad number of cases of valid and 
invalid combinations of complex XPointer References
which in turn are either part of a same-document reference or external 
references which have to be dereferenced, plus canonicalization,
plus XPath transformations, plus XSLT-Transformations, plus custom 
transformations and canonicaliztations which force many current XMLSig 
implementations to have the complete DOM document underneath.

>   B) Require a client to always send full, untransformed documents so 
> the server can apply any server-side transforms.

> In my opinion, the ability to send partial and/or transformed input 
> documents is crucial.  It allows a client to request a signature on a 
> small portion of a larger document, or access a generic server which 
> lets clients request signatures on any sort of transformed document.

I agree that partial and/or transformed input documents may be important 
for some applications.
There is also no indication that this is true for the majority as the TC 
has lately decided to go for B).
Further one should doubt that the whole issue is simple enough to remain 
part of the core.

On top of that where is the catch of moving this problem to a profile 
and calling things by their name?
I.e. Call an IntermediadeTransformationResult an 
IntermediadeTransformationResult and to do this in a profile .
Nevertheless the TC decided lately to do that and to move the complexity 
out of the core.

> [...]
> Perhaps this is a related issue, perhaps not, but I'm also concerned 
> by the proposal to remove 3.2 and 3.3, which describe simple 
> algorithms clients can use to produce enveloping and enveloped 
> signatures with a server that implements basic processing.

These are at most simple requirements.

Nevertheless these things should be discussed in a profile having 
defined an Optional input called IntermediadeTransformationResult.

best regards

Konrad