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

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

Dear all,
Hi Trevor,

this is my final comment in this specific discussion as it takes too much of my resources.
I hope Trevor you understand, that you'll have to go back to XMLSig and all the references I posted in this thread, to understand and finally respect the constraints XMLSig puts on us.
Nevertheless I appreciate the discussion a lot and hope it bears fruitful results.

Re- Normalization:

Okay, I looked through it briefly.  Thanks for pointing this out, this seems important

Well, I think we now agree on this, and that it has to managed in some way.

regardless of splicing.

However, I'm sure it has the biggest impact on splicing as splicing will be usually done in memory using some kind of DOM implementation and hence will have to be parsed.
The question now simply is do you want to manage it only for servers or do we have to manage it for both clients and servers.

Basically, the page describes options for a DOM parser, such as:
 - discarding whitespace not allowed according to a schema
 - discarding content whose values can be inferred according to a schema
 - discarding namespace declarations
 - re-encoding characters
 - re-encoding values to "normalized" form, i.e. "1" -> "true"

I think these things are bad, at least for basic processing, and we should add text to disallow them.

I agree, however you have to admit that this is easier to be enforced if it only has to be enforced at the server-side.
Also DSS has to be seen in the bigger picture. It will be embedded in SOAP-Binding and Webservice architectures.
Then one actually does not have control over the parser, i.e.: some Webservice/SOAP implementation did the parsing already for you and DSS is used as a part in a much larger XML based System.
Then one has to be able to add robustness and the server will have to be able to apply transforms if it wishes.

Default server behavior should be to sign what clients send,

I think you still do not see that this problem appears already when the client touches the data.
If the client opens a document on his hard disk or from the web by using an editor to views it this is not necessarily the same as what is sent.
Especially if the data has to be signed bit by bit (i.e. XMLSig Detached signature, external Uri, no transforms, no canonicalization).
The only way to do this is to base64 encode and not to touch it any more and to send it.
(Assuming consistent character encoding isn't an issue escaping might work as well.)
But as soon as the client parses the data to transform it etc.. normalization becomes an issue on the client side as well.

Splicing or embedding suffers similar problems and you might end up with a document containing parts of the signature being signed normalized and others being embedded unnormalized or the other way around. So the signature might never ever verify again. If signing and splicing is done by the server it can be assured to be consistent.

or add explicit transforms, *not* to silently discard portions, re-encode, or normalize it.

Hence the server might wish to do so in order to be robust against different normalizations.
To be able to do this it needs to be able to parse, transform and canonicalize the input.
To be able to parse and process the input it needs a complete document.

Re-client-side transforms issue:

[...]
(Thanks for the concrete example - This seems a good example for the client-side transforms issue,

Well, good you noted that as this was my intention.

not the splicing issue,

As you also have noted correctly, the first part (normalization) was about splicing.
(Although all these things are interrelated e.g. In some cases transforms depend on values that have been normalized and will hence behave differently. Normalization might also behave differently if not the complete document is parsed against a schema: You can find examples combining <xs:choice> containing <xs:element ...> and <xs:any ...> appropriately with client-side transforms to cut out the element and let it's content now match <xs:any ...>. And sorry I don't have time to come up with an example).

so I'll deal with it in that context.)

[...]
My proposal is that if the server wants to apply a transform such as this, it needs to operate under some profile or policy which requires the client to send the entire untransformed input document.

Please go back and read XMLSig including the references at the end of the document.
Then you will note that transforms including a *transform such as this* are an integral part of xml digital signatures, so I fear cannot give my vote to this restriction.1

Since many servers will place requirements on the form of input documents,

I hope that we will eventually agree on that a document (in the case of InlineXML, Base64XML, EscapedXML) is something one can parse at the server side and if the server wishes it is able to parse, analyze, and apply transforms on them.

Hence I strongly advocate to keep the recent changes and to not allow client-side transforms in the cases above and to keep the following amendments.

Base64Data should not allow client/server side transforms and just be embedded or hashed at the server. (e.g. an image)

DocumentHash remains for client side transforms as it is the least critical in terms of normalization: everything up to hashing is done by the client.

Further an optional input (input in a profile) should be added (to the core) representing a binary client side transform result.
The optional input could be called Base64TransformsOutput and should contain base64Data and have a <ds:Transforms> element with transforms already applied by the client.
The optional input should further have an attribute called justHash=true/false (default: true): if true the server just hashes and builds a <ds:Reference>.

If false the base64Data has to be a parseable xml document as the server will have to be able to parse the input for further processing.
This also implies the last of these client side transforms has to be a transformation/canonicalization returning parseable xml.

This new optional input is not a <dss:Document> and it is incompatible with <ds:SignaturePlacement> and <ds:EnvelopingSignature> as it's original input is unknown and hence cannot be spliced and echoed.


Re-form of input documents:

I think these requirements are best handled at the policy/profile level,

I disagree.

while basic processing should support the most general form of input documents.

Base64XML, EscapedXML (InlineXML with limitations concerning the prolog, context inheritance and external-uris) support already each and every well-formed xml document including.
Base64Data supports, binary data like Images, Binary Documents from your favorite office application etc.
Hence the problem is not about the most general form of input documents, it is about client-side transforms mixed with server side transforms, and that NodeSetData cannot be transmitted even not inside InlineXML.

best regards
Konrad