[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] REFORMULATED ISSUE#2: SIGNATURECONTENTS (SIGN REQUEST DISCUSSION)
I would say that if we take the req. document, it says that it has to be possible to take parts of the input document, sign them and envelope them. And it is the "envelope them" what is bringing these discussions. Let us suppose that what we call TansformsAToB the transformations to get B document, and TransformsBToC the transformations to be applied to get document C from B. In these conditions, the document referenced by the references in the ds:Signature element enveloping B, would be B, not A!!!. You would include in the ds:Reference elements ds:Transforms corresponding to TransformsBToC. As you would have the B document enveloped within the ds:Signature you could verify the signature. Indeed, you would not be able to recover A unless you would not store A (and the corresponding TransformsAToB) somewhere (but I think that this is part of the business case, and this can always be solved outside the scope of the work of this group). Think of it in another way: Imagine a workflow system. There some XML document containing lots of different types of informations comes in (document A). As the document progresses through the workflow, certain transformations extracting parts of de documents are applied generating a new document (B). And they are preciselly the contents of this derived document the ones that must be signed by a certain person (let us say the account department director) (after a new set of optional transformations....). This document B could be inputed to a local ds:Signature generator that would produce an enveloping ds:Signature including not all the document A, but only the document B with the ds:Reference elements including the second set of transformations... and the signature verification would be carried taking B as the actual input data for the transformations appearing in the ds:Reference elements. If this can actually be a reasonable business case, my opinion is that our server could also allow for this kind of behaviour. Juan Carlos. At 12:12 15/09/2003 +0200, Andreas Kuehne wrote: >> > - "selection transforms" A -> B, and the >> > - "signature transforms" A -> C, B -> C > >Shouldn't the reciever be able to reapply the mentioned 'signature transform' using the enveloped data ? It doesn't make sense for me to envelope some data which you could NOT use as a starting point for the 'signature transform'. You couldn't verify this signature without additional access to the original data. This would proof the enveloped data as redundant. > >I would prefer to allow only B -> C signature tranformations. The A -> B tranformation would degrade to be friendly service for the user. > >Or do I have missed an important aspect (again ) ? > >Greetings >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]