Re: [dss] suggestion for 3.3.3 (Action 05-07-25-1)

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

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.