More on EnvelopingSignature

[cruellas@ac.upc.edu]

Dear all,

Concerning our previous email, and after looking at the request
and thinking further,we would say that, as there is not in the request any ObjId
in 
the EnvelopingSignature optional input,and there is not any Id
in the enveloped xml data, the request is not correctly built and
the server would generate a signature whose verification would fail.
Requester's responsability....

But the issue on the description of the processing is still remaining.
If the request is:

<dss:SignRequest 
xmlns:dss="http://www.docs.oasis-open.org/dss/2004/06/oasis-dss-1.0-core-schema-wd-30.xsd";;

RequestID="UPCRequestEnvelopingXMLSig_0">
    <dss:OptionalInputs>
        <dss:SignatureType>urn:ietf:rfc:3275</dss:SignatureType>
        <dss:EnvelopingSignature WhichDocument="BinaryDocId0" ObjId="data"/>
    </dss:OptionalInputs>
    <dss:InputDocuments>
        <dss:Document ID="BinaryDocId0" RefURI="#data">
            <dss:XMLData>
                <upc1:Root 
xmlns:upc1="http://www.ac.upc.edu/namespaces/ns1";; 
xmlns:upc2="http://www.ac.upc.edu/namespaces/ns2";;>
                    <upc1:Child1 xml:lang="EN">child1 content</upc1:Child1>
                    <upc2:Child2>
                        <upc1:Child21>child21 content</upc1:Child21>
                        <upc1:Child22>child22 content</upc1:Child22>
                    </upc2:Child2>
                    <upc2:Child3>
                        <upc2:Child31>child31 content</upc2:Child31>
                        <upc2:Child32>child32 content</upc2:Child32>
                    </upc2:Child3>
                </upc1:Root>
            </dss:XMLData>
        </dss:Document>
    </dss:InputDocuments>
</dss:SignRequest>

Then the server is instructed to add the Id attribute to ds:Object. In this
case, in order the verification be successfull, the server has to digest
the whole canonicalized ds:Object, not only the xmldata contents....and this
process is not indicated anywhere in the core text.....


Going a bit further, we could have three general cases....The list below
explains them and gives indications of what we think that the server 
could do in each case. We asume in all of them that the to-be-enveloped
input document contains a RefURI....if not, things are per-application
based (as indicated in XMLDSIG).

1. EnvelopingSignature without ObjId, NO SignedReferences with Transformations,
No transformations indication in the input document:

---> If the input document is a XMLData and it contains an Id that matches
the RefURI, the server should only process (canonicalize and digest) the
contenst of the element with the Id for generating a valid signature!!.
Difficulties for the server, unless the Id is in the root node of the
input document....If not Id is present in the document there is no way
of generating a valid signature: Requester's responsability....
What about banning this request?

2. EnvelopingSignature with ObjId and NO SignedReferences with transformations
AND NO transforms indication in the input document.

---> For generating a valid signature the server SHOULD PROCESS (canonicalize 
and digest in this case) the whole ds:Object (Not indicated in 
the core: need for modification?)

3.EnvelopingSignature with or without ObjId AND some transformations within
the inputdocument or within SignedReferences.

--->The server will process THE INPUT DOCUMENT as indicated
in the section corresponding to processing, and the client will be 
responsible for ensuring that the corresponding RefURI/Id pair
and the transforms indicated and/or requested combine so that the built
signature may be successfuly verified....Again, it is client's responsability.


Do you agree with the summary of the 3 different cases? and what do you think
of the server's behaviour that we describe for them?

Regards

Sergi and Juan Carlos.