Schema TP5. ISSUE#1: Already applied transformations by the client

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

Dear all,

After reading the document and the schema I have some comments that 
I will send in different messages in order to separate the 
topics.

The first one deals with the transforms that purportedly the client
has performed on the documents and their relationship with the 
document that it is sent, signed and how the ds:Reference elements
are built in such occassions.

I think that the text in section 3.3 (Basic Processing)
could be interpreted in a way that could lead to situations
where the server would produce enveloping
signatures which, when somebody would try to verify, would
always fail....


First, I will reproduce some text below:

- Lines 110 and following state:
"The <InputDocuments> element is used in request messages to 
send documents to a DSS server, whether for signing, 
verifying, or time-stamping"

So, first assertion:  whatever it is in the InputDocument
is WHAT the client sends to the server for signing (in our
present discussion).


- Lines 147 and 148 say:
"<ds:Transforms> [Optional]
A list of transforms that have already been applied to the document."

So, second assertion: the client can have computed a number of
previous transformations to the document that originally he had.

Now some notation: 

. Let us  call DOC-0 to the INITIAL DOCUMENT to which the client
has gained access.

. Let us call TS-0 the set of transformations that the client 
applies to DOC-0, and that are indicated with the corresponding
XML elements within ds:Transforms mentioned in lines 147 and 148.

. Let us call DOC-1 to the document resulting from applying 
TS-0 to DOC-1.

First question: which one, DOC-0 or DOC-1, is the client
sending to the server?... well, the text in 147,148 
("a list of transforms that have already been applied to 
the document") seems to indicate that in fact is DOC-0 
(this is the ONE TO WHICH THE CLIENT HAS APPLIED THE TRANSFORMS).


Then, let us asume that it is DOC-0 the one that the client 
sends... A first question would appear: why a client would
compute a set of transformations to get DOC-1 and then
send DOC-0? We can, nevertheless proceed further and follow
what will happen...

According to the text (lines 288 and following) in basic 
processing, the server...


"•	The server hashes each input <Document> or <DocumentURI>."
--> Let us forget about the <DocumentURI>... we only have one Document: DOC-0.
the server computes its Hash: HDOC-0.

"•	The server forms a <ds:Reference> for each input document out 
of its RefURI, RefType, <ds:Transforms>, and hash value."

--> What I understand from this text is that if there
is not RefURI, no RefType but a ds:Transforms in the 
request, the server produces a <ds:Reference> that 
includes ds:Transforms and the hash of DOC-0: HDOC-0.

In our case, the server would put DOC-0 within a ds:Object
and would generate the ds:Signature.

Now, let us go to the verification process. According to XMLDSIG,
the verification process would be:

-First step is to canonicalize ds:SignedInfo...the interesting part
for us is the next one:

"2. For each Reference in SignedInfo: 
2.1 Obtain the data object to be digested. 
(For example, the signature application may 
dereference the URI and execute Transforms provided 
by the signer in the Reference element, or it may obtain the 
content through other means such as a local cache.) "

---> In our case (enveloping signature), the dereferencing would
lead us to get DOC-0. Then we would EXECUTE THE TRANSFORMS appearing
at the ds:Reference!!! getting DOC-1!!


"2.2 Digest the resulting data object using the 
DigestMethod specified in its Reference specification. 
Compare the generated digest value against DigestValue
in the SignedInfo Reference; if there is any mismatch, validation fails. "

---> Well, here we are: now we compute the hash of DOC-1 and get HDOC-1, 
WHICH WOULD BE DIFFERENT OF HDOC-0 THAT APPEARS IN THE ds:Reference!!!


Somebody could say: "wait a moment!, it is not DOC-0 but DOC-1 the document
that the client sends in the InputDocument!". 
Well, even in that case the processing would lead to bad ds:Signature elements.

Suppose that the client sends DOC-1. In this case, according to the basic
processing of our document:

1. Computes the hash of DOC-1: HDOC-1.
2. Generates the ds:Reference with the ds:Transforms that the client  has
applied to DOC-0 to get DOC-1.
3. ENVELOPES DOC-1 WITHIN A ds:Object of the ds:Signature. AND HERE IT IS
THE PROBLEM FOR THE VERIFICATION.

In the verification:

2.1 the dereferencing would get DOC-1. Then the transformations that
the verifier would apply would lead him to a DOC-2 completely different!!
and 2.2 would, of course fail!.

In addition, should not the basic processing text include the addition
of a base64 transformation by the server in the ds:Reference of a doucment
that has been transferred to the server encoded in base64? I understand
that the text is proposing to keep it encoded in base64 (I would like  to
discuss whether this is unavoidable...it seems weird to have to
encode base64 XML docs. when signed by a server that will produce XMLDSIG!,
but I will send another message on this particular point.)


All these problems come from section 3.4.2 in the req. document.
It says: 
"The client may send an input document in unaltered form, 
or may apply some transforms and send the transformed data, (..) 
Transferring the document unaltered or transformed allows 
the server to archive and review what it is signing or verifying ".

It seems that it is saying that in these cases the client should
send DOC-1, not DOC-0! BUT if I am right in my previous discussions,
then the ds:Transforms already applied to DOC-0 to get DOC-1 should not
be transferred. 
In that case, the text and the schema should be corrected accordingly.


Of course, there would be an alternative: to transfer both, DOC-0
and DOC-1 (the initial and the result of transforming it!), so that the server
could compute the hash on DOC-1 and envelope DOC-0!, but I guess
that there will be very few people in favour of that?

As a conclusion to all this stuff: I think that we have to clearly identify
WHETHER we still want to explicitly deal with this req on transforms
already applied by the client when the client demands an enveloping signature


Sorry for sending this email so late..

Juan Carlos.