[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dss] suggestion for 3.3.3 (Action 05-07-25-1)
Hi Juan Carlos, [...] > imagine that > the client puts a same-document RefURI in a document, and that it does > not incorporate any SignaturePlacement > or InsertDocument elements. Under such circumpstances I would say that > the client is instructing the server > to build a ds:Reference with a same-URI document, and to return as a > dettached signature for taking it and > splicing in the document by itself, isn't it? I think that explains in brief what client-side splicing can be useful for, but as you have seen in the previous discussions and in the following example things are not as easy as that. Speaking in XMLSig lingo a signature like that would not be a detached signature as it cannot stay and verify alone. It needs the correct splicing to be done before the signature is calculated and not afterwards. Thanks however for distilling client-side splicing to it's core. Example: Consider four same-URI documents (dss:Documents having reference-only RefURIs, I presume). The first one having RefURI="" the second one having RefURI="#xpionter(id('ObjID1'))" the third one having RefURI="#ObjID2" the fourth having RefURI="#xpionter(id('Signature1')/ds:Object)" The first could be understood to create a same document-ds:Reference and to apply an EnvelopedSignatureTransform, the second could be understood to generate a ds:Object having an ID="ObjID1" plus the according ds:Reference, the third could be understood to generate a ds:Object having an ID="ObjID2" plus the according ds:Reference, the fourth having RefURI="#xpionter(//ds:Object)" can be understood to generate a ds:Object not having an ID, which is allowed for at most one ds:Object plus to set the Signatures ID attribute to Signature1. Note: This is all guessing and horrible for interop as everybody will understand things differently. The problem with client side splicing now is that the fourth RefURI actually causes all three <ds:Object> elements contained in Signature1 to be dereferenced and hashed. So if the server does not place them where they are going to be at the end this will never verify again. Extended-Example: If this is not complex (ambiguous) enough, simply let the RefURI of the first same-URI document be "#xpionter(/ | id('Signature1')/ds:Object)". Which could be understood to generate a ds:Reference having URI="#xpionter(/ | id('Signature1')/ds:Object)" plus an EnvelopedSignatureTransform. Further it would hash everything but the Signature excluding it's Objects. (Everything outside the signature, plus all the Objects of Signature1). If you ever want a verifiable signature for this the server will have to place everything in the right position before signing or the first and the last reference will always break. And if he does so why should he remove the previously spliced and placed parts again to have them spliced hopefully in exactly the same way by the client again. best regards Konrad P.S.: Issues like these are also true for dss:DocumentHash and it should be discussed whether one <dss:DocumentHash> implies that all documents have to be <dss:DocumentHash> so that the client can correctly dereference nodes referenced by multiple <ds:Reference> elements or if they should be restricted to external-URIs assuring that the dereferenced node sets are disjoint and independent. This point however should not be discussed until the core has stabilized again. Note if client-side splicing and client-side transforms are not allowed, a server may try to verify the signature before returning it and can be pretty sure that the signature will remain verifiable, because it's not tampered with any more by the client.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]