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

[Trevor Perrin <trevp@trevp.net>]

Konrad Lanz wrote:
[...]
> 
> doc != doc'  is then allowed.
> 
> However this contradicts basic processing as the server must be able to 
> apply transforms if it whishes and the .

I think we disagree about what it means, or should mean, for the server 
to apply transforms "if it wishes".

I don't think this means that it is desirable for basic processing to 
require clients to submit <InlineXML> in a form such that every 
server-side XML-based transform is possible.

If this is a necessary restriction on clients to avoid horrible 
problems, well, so be it.  But this *restriction* is not desirable for 
other reasons.

It would be desirable for basic processing to allow clients to submit 
data in a general form, and to restrict basic processing servers to only 
applying transforms compatible with that form.

Servers which wish to apply additional transforms would specify 
additional constraints on input data, as a matter of profile or policy 
(e.g.: no client-side transforms for <XMLData>; or <Base64Data> must 
contain an EDI record; etc.).

The general form for <Base64Data> would be unstructured data, which the 
server should do nothing but hash.  The general form for <XMLData> would 
be parseable XML to which Exclusive Canonicalization could be applied to 
convert it into Canonical XML.

As long as the client wishes to applies transforms which produce such 
data, or the server wishes to apply transforms which consume such data, 
as part of basic processing, they should be welcome to do so.

Anyways, this doesn't seem to require much more in the core than some 
clarifications.

Are there horrible problems with this?


(Below I respond to Nick's thread, but repeat the same points)

 > Nick Pope wrote:
 >
 >> I suggest that the default is to apply the canonicalization as
 >> required by
 >> XMLSig, but have a attribute set by the client to indicate that any
 >> necessary transforms have been applied by the client and all that the
 >> server
 >> is required to do is perform a hash.
 >>
 >>
 > This is possible and the attribute could be an attribute of Base64Data,
 > but I'm not sure if Base64Data is the right place to indicate this as
 > we'd loose the clear separation between what is/was an xml document and
 > what is a binary document.
 > Also to be able to form a <ds:Reference> the server needs information
 > about the <ds:Transforms> applied.
 > Hence may I suggest that we allow this in combination with an optional
 > input, to only have a small change to the core.
 >
 > Alternatively we could also seperate InlineXML, EscapedXML, Base64XML
 > from DocumentHash and Base64Data by using different BaseTypes.
 > InlineXML, EscapedXML, Base64XML: cannot support client-side transforms.
 > DocumentHash: everything is done by the client.
 > Base64Data: everything, but hashing is done by the client.
 > The latter two require ds:Transforms to be communicated.

I would prefer to say that by *default* <Base64Data> is unstructured, so 
that only hashing could be done by a server.  But it should be legal for 
a server's profile or policy to apply additional constraints to the form 
of <Base64Data> so that the server could apply transforms to it.

Also, I would prefer to allow transforms on all inputs.  In the case of 
XML, by default the transforms would have to result in data which the 
server could Exclusive-Canonicalize and then sign, and the server would 
be restricted to transforms compatible with data in this form.



> 
>>>  - If the transform results are not XML, send them in <Base64Data>.
>>> The server should not assume <Base64Data> has any particular form unless
>>> the profile has mandated it.  I.e. by default the server should only
>>> hash it, not apply transforms.
>>>   
> 
> see answer to Nick's suggestion above.
> 
>>>  - If the transform results are XML, they should be sent with enough
>>> namespace context to support canonicalization through Canonical XML.
>>>   
> 
> i.e. a parsable xml Document, as canonicalization requires NodeSetData 
> as input and can only retrieve this NodeSetData which is to be retrieved 
> from a parsable xml Document.

Is my proposal clearer above? - If the client sends an XML fragment 
which includes all namespace context, isn't that sufficient for the 
server to canonicalize it? (and perhaps apply other transforms)?


> 
>>>  - Profiles which wish to support server-side transforms which require
>>> additional context, or require Input Documents of a particular form
>>>
> e.g. canonicalization is such a server-side transform, and I think we do 
> have to support it.
> 
>>> [...]
>>>   
>>> These rules would clarify the core
> 
> Not to having to deal with all these issues in a basic processing is a 
> lot clearer from my point of view.
> A profile (or optional input) allowing client-side transforms provides 
> you with enough room to discuss it extensively.
> 
>>> while leaving its basic functionality
>>> intact.
>>>
> This was broken in previous versions of the core.
> 
>>> [...]
>>>
>>>> [...]
>>>>
>>>>> But you should still be able to send it as [...]
>>>>>
>>>>> <Base64Data>.
>>>>>       
>>>>
>>>> Could you please explain, how you'd then parse the non-XML octet stream
>>>> using an xml parser. It's not possible as it is not XML.
>>>>     
>>>
>>> A basic processing server should not do this, it should just hash the
>>> octet stream.
>>>   
> 
> That implies that everything, but hashing has been done by the client 
> and the server may not whish in this case to apply additional transforms.
> Hence the mixed case is ruled out.
> 
>>> Again, I believe that having the client apply transforms but the server
>>> apply the hash algorithm has value in certain circumstances.
>>>
>>> (Ditto for having the server apply transforms, canonicalization, and
>>> hashing in the XML case.)
>>>   
> 
> see suggestion at the top.
> 
>>>>> [...]
>>>>>       
>>>
>>> If the server is going to splice the signature into an XML document, it
>>> needs to know which document and where to splice, doesn't it?
>>>   
> 
> Use: <dss:SignaturePlacement>

Oh, okay, I thought you wanted to make enveloped sigs part of basic 
processsing too.


My question below is still outstanding, as for why servers will be 
signing documents which are different from what clients send, so that 
document-splicing on the client-side will be unreliable.

If anyone understands and could explain it, I'd be grateful.

"""
Could you explain in detail, with some examples?

Maybe I'm just naive, but it disturbs me to imagine the server operating 
on a different XML document than the client sent, without this 
difference being represented in the transform chain.

Put another way: this seems like a bigger issue than just 3.3.2 and 
3.3.3, and I'd like to understand it, to see what other ramifications it 
has on the core, such as Security Considerations.
"""

Trevor