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

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

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.

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.
Hence almost all server-side transforms are ruled out, as the following.

Canonicalization: (http://www.w3.org/TR/2001/REC-xml-c14n-20010315#DataModel)

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.

XPath-Filter: (http://www.w3.org/TR/2002/REC-xmldsig-filter2-20021108/#sec-EvalContext)

The input required by this transform is an XPath node-set over the input document. If the input document is an octet stream, then the application MUST convert the octet stream to an XPath node-set that contains all of the document nodes (including comment nodes).

XSLT: (http://www.w3.org/TR/xslt#data-model)

The data model used by XSLT is the same as that used by XPath [...]

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

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.

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.

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.

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.

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.

[..] I agree the specs could be more detailed here [...]

I'm happy that we agree on that.

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.

[...] If you want the server to do something additional, like document splicing, [..]

According xml digital signatures I would not say that this is additional: (http://www.w3.org/TR/xmldsig-core/#sec-Object)

 [...] This element is typically used for enveloping signatures where the object being signed is to be included in the signature element. The digest is calculated over the entire Object element including start and end tags. [...]

However the server has to use DOM implementations anyway so splicing is a cheap operation there. Hence the client can remain slim.

[...] I think the belief was that such a core is easiest to build off of when spec'ing, implementing, and interoperating.

I disagree, as I'm also implementing these things as well.

That's a fuzzy argument but it's getting late.

With all due respect, I fear It is really too fuzzy.

[...]

best regards

Konrad