Question on one EnvelopingSignature Optional Input case

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

Hi,

While developing soft for the signing protocol we have faced an issue
that seems to require further clarification: the precise processing of
<EnvelopingSignature> optional input in certain situations.
The issue may be described as follows: the basic processing rules described
in section 3.3 estblish that the server takes the contents of the XMLData,
for instance, canonicalize it, performs the transforms that it wants and 
hashes it.
This seems to be clear for enveloped and detached signatures, but it is not
clear that this is what should be done for all the enveloping signature 
requests.
Imagine you receive the following request:

<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"/>
    </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>

If we strictly follow the text of the core, we should put the URI in the 
reference and
digest the document....but if the enveloped document does not have the 
corresponding Id
attribute the signature would fail!!!. A different way of generating the 
signature
would be to build up the enveloping ds:Object, put the document in it, 
add to the ds:Object the Id="data"
canonicalize the ds:Object and digest it....Is this
the way we should understand the expected behaviour?
I see two alternatives:

1.Not allowing this request, ie, forcing usage of Transforms (XPath, for 
instance)
for getting what we actually want to get and envelop.

2. Allowing this request and write the suitable text in the core.

Do you have any views on that?

Regards

Sergi and Juan Carlos.