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

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.