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

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

Hi Trevor,

Trevor Perrin schrieb:

I still don't see why it's hard to transmit intermediate transform results as XML.

I probably should not call them results as results could be understood as something that can be serialized, transmitted and parsed again remain the same NodeSet without loss of Information.

Most of the complexities you talk about only seem to apply in the case of certain server-side transforms (but not canonicalization).

Please bear in mind that results of a canonicalization are binary and only parseable if they are complete well formed documents.

Please see: http://www.w3.org/TR/xmldsig-core/#sec-ReferenceProcessingModel

If the data object is an octet stream and the next transform requires a node-set, the signature application MUST attempt to parse the octets yielding the required node-set via [XML] well-formed processing.

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?

I presume that reading the specs of canonicalization could help to understand the issue. (please see: http://www.w3.org/TR/2001/REC-xml-c14n-20010315#DataModel)
I understand that many things there are difficult to grasp, hence I have quoted the relevant statements below.

[...]

The first parameter of input to the XML canonicalization method is either an XPath node-set or an octet stream containing a well-formed XML document. [...]

[...]

If an XML document must be converted to a node-set, XPath REQUIRES that an XML processor be used to create the nodes of its data model to fully represent the document.
[...]

The input octet stream MUST contain a well-formed XML document, but the input need not be validated.
[...]

So to summarize that a canonicalization needs a Node-Set as input which it can only retrieve from random access memory of a computer having the complete DOM Document or it needs an octet stream representing a complete Document.

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.

Functionality has to function, right?

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.

I agree, but I fear that many people would not have a hard time in actually implementing it correctly.
Hence the decision for moving it to a profile where people concentrate on these issues without having to bother others that are happy with the simple way.

Other comments inline -

[...]

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.

Tell me what is XML?

Under the assumption that parts of the prolog and PIs and Comments after the DocumentElement can be ignored,
I would say it is well-formed and it has a single DocumentElement and hence is a subset of a NodeSet and not the other way around.

Proof:

[attrbute Node: key=somekey; value=soemvalue, namespace=somenamespace, ... ]
<elem1 />
<elem2 />
<elem3 />

Is a NodeSet, but not well formed XML as it has more than one DocumentElement.
On the other hand side simply select the whole XML via X-Path and and every Document (prolog and PIs and Comments after the DocumentElement ignored) is a NodeSet.

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?

Is this XML?

[attrbute Node: key=somekey; value=soemvalue, namespace=somenamespace, ... ]
<elem1 />
<elem2 />
<elem3 />

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

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

This was meant to be an Example for a NodeSet containing 4 attribute nodes, followed by element nodes called element1, element2 that in turn contains element3 and a text node having a value " " followed by another text node containing a CDATA character data value <![CDATA[ ... ]]>
and the followed by another text node having the value " ".

I would not call this XML, but I'd call it a NodeSet.

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.

Try to properly define a serialization for NodeSets, I fear you'd really inflate the core significantly.

[...]

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?

A subset of combinations of those which I find quite difficult to express explicitly.

[...]

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.

and wide enough not to be too restrictive. (Typo)

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.

Try to enforce these restrictions on something you cannot parse into memory because it isn't well formed XML.

[...]

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

I would not call something that loosely specified an algorithm, especially in combination with the old point 3.3 and with client side transformations that cannot be transmitted.

best regards
Konrad