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

[Trevor Perrin <trevp@trevp.net>]

Konrad Lanz wrote:
> Hi Trevor,
> 
> Trevor Perrin schrieb:
> 
>> 1) Client-side transforms
>> [..]
>> After thinking about this, I think these aren't really problems, just 
>> acceptable limitations:
> 
> I know that these are problems and provided references to proof that in 
> my last email from the xml digital signature specification and the 
> canonicalization specification. Please go back to these references and 
> you will understand.

Konrad,

I thought I understood your points, which I tried to summarize:
  - client-side transforms do not always result in parseable XML
  - even when they do, this XML may not be amenable to additional 
server-side transforms due to missing context

Is this a reasonable statement of your points?

My point is this:  These issues require clarification in the core, but I 
think the following would be sufficient:
  - 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.
  - If the transform results are XML, they should be sent with enough 
namespace context to support canonicalization through Canonical XML.
  - Profiles which wish to support server-side transforms which require 
additional context, or require Input Documents of a particular form, may 
place additional constraints on <Base64Data> or <XMLData> (e.g., 
disallow client-side transforms, require XML that matches a particular 
schema, whatever).

These rules would clarify the core while leaving its basic functionality 
intact.  The core would still support client-side transforms in 
conjunction with server-side canonicalization, server-side hashing, and 
a subset of server-side transforms.

Since minimizing changes to the core is good, the above features are 
worthwhile, and the above clarifications are (I believe) sufficient, I 
don't yet see a need for re-dividing responsibilities between core and 
profiles.


> 
>> If your client-side transform produces non-XML, then it's obvious you 
>> can't send the result as XML.
> 
> I think we now agree on this.
> 
>> But you should still be able to send it as a hash
> 
> Yes, and we currently do so using <DocumentHash> and it is implied that 
> all transforms have been done by the client.
> This is possible with the currently drafted version.
> 
>> or <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.


> Hence almost all server-side transforms are ruled out, as the following.
[...]
> Hence only server side Hashing or some Encoding Transform with Hashing 
> remains, which could have been done by the client just as well and then 
> sent as <DocumentHash>.

I disagree that client-side hashing is a perfect substitute for 
server-side hashing.  This requires the client to know which hash 
algorithm is acceptable (not an easy thing these days), and contain code 
to implement it.


> 
> So the client will have to send a Document. So this means the last 
> client side transform would have to be a canonicalization with the 
> restriction to return a complete stand alone document without further 
> dependencies. So there is not much value then in doing any further 
> processing at the server and you could just as well do the hashing at 
> the client.

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


> 
>> If your client-side transform is incompatible with certain server-side 
>> transforms, then the server can't apply those transforms.
> 
> Incompatible here would mean not to send a complete independent xml 
> document.
> 
>>   It should be up to profiles to allow/disallow client-side or 
>> server-side transforms as appropriate.  There are use-cases where you 
>> only want client-side transforms, only want server-side transforms, or 
>> want mixes of both.
> 
> If you want client-side and server-side transforms for the same 
> ds:Reference at the same time, this should be done by an optional input 
> in a Profile.
> 
>> [...]
>>
>> 2) "Document splicing" for enveloped/enveloping signature (3.3.2, 3.3.3)
>>
>> Konrad expressed a desire for the server to always return verifiable 
>> signatures (i.e. signatures with all enveloping and enveloped 
>> documents attached), so the client would not have to do splicing 
>> itself, or trigger an optional input to request server-side splicing.
>>
>> I believe this would mean eliminating 3.3.2 and 3.3.3,
> 
> Yes, it would.
> 
>> and moving the functionality currently described in 
>> <SignaturePlacement> and <EnvelopingSignature> into core basic processing,
> 
> No it wouldn't.

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?

If the server is going to splice documents into an XML signature, it 
needs to know which documents, doesn't it?

So clearly you're proposing adding some sort of additional functionality 
to basic processing, with some additional guidance provided by the client?


> 
>> while adding an optional inputs that requests returning an "unspliced 
>> signature" instead of the spliced one.
> 
> Yes it would, and could also be done in a profile. Explicit requirements 
> of how this splicing would have to be done and how to overcome problems 
> appearing when splicing has to be done by the client could be discussed 
> there extensively.

Okay, but I'd like to first understand what these problems are, and what 
the discussion is going to look like, before we decide where to put it.


> 
> This is not as much of a problem with <DocumentHash> and same-document 
> references as the client will exactly know each and every character and 
> every bit, that it has dereferenced, parsed, how it was parsed (ref. 
> datatype normalization, validation), transformed, canonicalized and hashed.

If this feature works fine for <DocumentHash>, then we should at least 
leave it in subject to this qualification.


> 
>> One of Konrad's concerns with the current approach is that it might be 
>> error-prone for clients to do splicing, as they might forget or do it 
>> incorrectly.
> 
> Exactly, as we have no guarantee that, parsing was done in the same way, 
> namespace declarations will still be in the same place etc.. .
> 
>> Another concern was "datatype normalization".  I'm probably not 
>> explaining this right, but the idea was that "datatype normalization" 
>> might cause the value the server signs to be different from what the 
>> client thought it sent, so that the client splices the signature with 
>> a slightly different document than was actually signed.
> 
> Exactly.
> 
[...]
> 
>> As for datatype normalization, I don't understand.  Is this a problem 
>> with an unreliable transport, or incorrect server parsing, or the 
>> presence/absence/difference of schemas on the client and server ends?  
>> [...]
> 
> It's a problem with client and server parsing, depends 
> presence/absence/difference of schemas and will behave differently in 
> most combination and should be discussed extensively. Again, there would 
> be enough room for this in a profile to keep the core slim.

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