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

[Trevor Perrin <trevp@trevp.net>]

Konrad Lanz wrote:
> 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.

I don't want to manage it, I want to disallow it.

I seems to me crucial that the server not silently discard or re-encode 
content before signing.

If this behavior must be tolerated in some profiles, then these profiles 
can apply restrictions on client splicing.


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

Yes, but isn't it also assured to be consistent if the server signs the 
XML the client *sent*, without normalizing or re-encoding it, and the 
client splices the same?


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

Of course, that's not the issue.

This is a tough design question about the default mode of DSS, the value 
of certain use cases, the relationship between core and profiles, etc. 
The answer isn't going to be found in the Dsig spec.

Well, I don't have much more to say.  I guess we're in the good hands of 
Konrad and the rest of the group to sort it out :-)


Trevor