RE: [dss] Question on one EnvelopingSignature Optional Input case

["Edward Shallow" <ed.shallow@rogers.com>]

Yes, building it up is what I assumed and implemented in order to alleviate
the caller from having to do so. I believe the whole value of enveloping is
"Please sign this document, put it in an envelope, and send it back to me".

This naturally implies straight XML document/data structures (perhaps with
decl and PI lines again ;)

-----Original Message-----
From: Juan Carlos Cruellas [mailto:cruellas@ac.upc.edu] 
Sent: May 27, 2005 6:49 AM
To: DSS TC List; scabre@ac.upc.edu
Subject: [dss] Question on one EnvelopingSignature Optional Input case

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-sch
ema-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.


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php