Re: [dss] REFORMULATED ISSUE#2: SIGNATURECONTENTS (SIGN REQUEST DISCUSSION)

[Juan Carlos Cruellas <cruellas@ac.upc.es>]

Wait a moment.... I think that we have to spend some time to clarify all
this issue,
to see if I have misunderstood things in your messages and in the
requirements document.

First I would like to reproduce below some text of messages, specs and req.
document, and 
some comments.

-Message from you to me directly  on August 15th (subject: dss schema). You
said:
"By using  Document Selectors as a layer of indirection, a client could
send a single 
document, then have multiple Document Selectors apply different transforms 
to it (to select different elements, for example), and then sign all these 
different references, and envelope some of them in the signature, and not 
others."


-Requirements document version 12. Section 3.5.1 Selective Signing.
"There the text says:
	.Which elements to sign
	.Which transforms to apply
	.Whether the element should be enveloped in the signature.
The client may specify which particular parts of the documents he sent he
wants
to sign, how these should be transformed, and whether they shoudl be
enveloped inside the signature."


COMMENT: For me this means that the text says that it may be the case that
a requester
sends an Input document, A. He has to send in fact two informations to the
server:
	1. Information on what elements of the input document A have to be signed.
	2. Information of the additional transformations that the server has to
apply to these elements.
Now the server does the following:

1. It builds up B (set of elements that will eventually be signed) from the
information in 1. This information
sent by the requester can be a XSLT transformation or a XPath expression.

2. It builds up C by transforming B according the indications in additional
transformations.

3. It envelopes B!!! in the signature. At least this is what I understand
from the text.


-Definitions of enveloping signature in XMLDSIG:
Signature, Enveloping 
The signature is over content found within an Object element of the
signature itself. 
The Object (or its content) is identified via a Reference (via a URI
fragment identifier or transform). 

This means that if the req. document uses "they should be enveloped inside
the signature", it is 
saying that within the ds:Signature there will be an Object element
including B and that the
Reference element will make a reference to B.

If I have correctly understood the text in the req. doc. this means that it
may be cases where not
the input document will be enveloped within a signature, but the resulting
of the selection.
This impression is reinforced by the appearance of the flag Enveloped for
EACH selector
in your schema.

My point is that (again, if I have not missunderstood the texts) the
service allows the signature to
envelope the results of transforming an input document, and this means that
within different
Objects there will appear these documents, and that the corresponding
ds:References within 
ds:Signature will point to THESE Objects, NOT to the original document !!!.

Having understood that, I also understood that it was our intention also to
allow to envelope
the signature within the resulting document after applying the
corresponding selection of elements.
As for if it is or not the meaning of enveloped signature in XMLDSIG below
follows the definition of enveloped signature:

Signature, Enveloped 
The signature is over the XML content that contains the signature as an
element. The content provides the root XML document element. Obviously,
enveloped signatures must take care not to include their own value in the
calculation of the SignatureValue. 

Conclusion: if a XML document contains a ds:Signature that contains the
adequate ds:Reference elements,
ie, a set of ds:Reference elements whose processing leads to correct
signature verification, that is an enveloping
signature.
And certainly the server could build up the correct ds:Reference element
for allowing the insertion of the
ds:Signature in document B. So, I think that I was not going against the
concept of 
enveloped signature as defined in XMLDSIG but, perhaps against 
what the dss TC documents understood by 
"Signature embedded in document (if an enveloped siganture was requested)"
Anyway, I admit that this is making things more complicated.
So, you seem to say that the meaning of the text in the req. doc is the one
you mentioned?
If so, we are allowing a kind of asymmetry in terms of what the server can
do: it can make
signatures enveloping different parts of the input documents, but it can
not make enveloped
signature in one of these different parts?

If this is the case, then the reference should point to the Input document.

But now, coming back to my proposal, if we do not allow to envelope the
signature within
a document resulting from some transformation of the input document, 
I still consider that what you call selectors
are more than selectors: they also give information of the relative
position between
signature and documents. My point is that following your proposal, the
software of the 
server should look at two places of the request message for dealing with
all the work
with the different documents: those dettached or enveloped would be
discovered in the 
list of selectors and the enveloping one some
elements afterwards in the tree when it finds what we are calling
SignaturePlacement.
I would say that in these circumstances,
to put what we are calling SignaturePlacement as a child of the new element
that I proposed wit semantics of  " final docs to be 
signed and position relative to ds:Signature" would compact all the
information of relative
positions of docs and signature in once....




Juan Carlos

>
>I don't think A3 *will* contain the ds:Signature.  The InputDocument that 
>was transformed to A3 will contain the signature.  So you would want to 
>indicate with an integer the corresponding *InputDocument*, not 
>DocumentSelector.
>
>Thus it doesn't make sense to associate a SignaturePlacementType with 
>DocumentSelector, as you propose.  Do you agree?

>
>Trevor
>