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

[Trevor Perrin <trevp@trevp.net>]

Konrad,

Thanks for the response.

I still don't see why it's hard to transmit intermediate transform 
results as XML.  Most of the complexities you talk about only seem to 
apply in the case of certain server-side transforms (but not 
canonicalization).  If there are complexities or limitations that apply 
in the case where the server only applies canonicalization to the Input 
Documents, could you clarify them?

As you said, we could move this functionality (transmitting Input 
Documents which could be transform results) to an Optional Input.  But 
we could even more easily move the *restriction* against this 
functionality only to those profiles that require it (i.e., if a profile 
allows complex server-applied transforms, the client must send full, 
untransformed documents.  But this restriction need not hinder other 
profiles).

Since this functionality is simple to achieve in the common case where 
the server is *not* applying complex transforms, is crucial for many use 
cases, and has been an integral part of the core for a long time (thus 
implying a degree of TC acceptance), discarding it at the last minute 
seems rash.  Fixing problems with the specs is one thing, but dumping 
key functionality at this date is another.

At the least, any proposal for re-designing this part of basic 
processing should include an Optional Input that achieves this 
functionality, so that profiles can add it in.


Other comments inline -


Konrad Lanz wrote:
> 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 name seems less important than what it is: XML the client is asking 
the server to sign.


> 
> 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.

XML?


> 
>  (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.

Sorry, I don't understand the previous two paragraphs, perhaps an 
example would help.


> 
> 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.

Examples would help here too.


> 
>> 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.

A subset of what?  XML documents?  Transforms?


> 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.

I'm not sure which XPointers or transforms you're talking about.


> 
> 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.

I don't see why this is a problem for the core.  If your profile allows 
server-side transforms which require certain restrictions on the Input 
Documents, then those restrictions should be part of the profile.


> 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).

I can't argue with that.  However, not everyone is always present, 
paying attention, or remembering arguments that were settled long ago, 
so I think conservatism here is appropriate.


> 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.

I'm not sure what you mean by that.


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


Trevor