OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[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]