Comments to local signature computation draft 18 October

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

Dear all below follow some comments to the draft of local signature 
computation draft of 18th October 2012. I have read until clause 3 
included...Hope to be able to read the rest during this week.

Regards

Juan Carlos.

0.0 In some places it is used (secure) signature-creation device....in 
others only signature-creation device. I would say that at least in some 
places the first term would also fit instead the second (for instance in 
second paragraph of clause 1.7. Suggest to use the first one unless the 
context is clearly demanding a different one (like the two bullets in 
1.7 where it is correctly used secure signature-creation device.

0.1. In most of the places it is mentioned "the document" as the 
document to be signed...however, the DSS core actually allows (for XML 
signatures) to collectively sign different data objects...would not this 
"the document" be a bit misleading and make readers to asume that the 
profile only will work when one wants to sign only one 
document?....would it be better to have a different wording like "the 
data object(s) to be signed" or something like that?

1. Clause Introduction:
. Maybe slightly change the wording:
"This profile extends the OASIS DSS protocol such that a (secure) 
signature-creation device (an SSCD
or SCD), under the direct control of the user, is used for the actual 
computation of the digital signature value".

2. Clause Abbreviations.
SSCD: I would say that this should be fully aligned with the definition 
of the EU Signatures Directive as this is the place where the term is 
coined?
RP: the explanation of what a Relying Party is seems confusing...uses an 
identity provider?

3. Clause 1.6 Requirements

. Rewording?: The overall goal of this profile is to extend the
OASIS Digital Signature Service (DSS) protocol such that a signature can 
be created by means of a
(secure) signature-creation device under the direct control of an end 
user. This section lists the requirements identified for achieving such 
a goal.

. Not sure to understand the last bullet.
"It shall be possible for a given PKCS#1 signature together with a given 
hash algorithm and given
input document (and document type) to obtain the signed document, using 
the given signature"

4. Clause 1.7. Design Rationale

. Suggested rewording first par, last sentence to:
"The resulting signature (and whenever requested the document) is sent 
back to the client in the
SignResponse (5). This is shown in the figure below."

I would say that unless anything is stated agaisnt the signature 
generated by default is the detached one and that what is relevant is 
that the signature is generated and sent back to the requester.

. Just above figure 2. I am not sure to understand the "resp." within 
"Note that the connection between the LSCD resp. RSCD and the Digital 
Signature Service still
has to be defined"

."Especially incase of a LSCD the Digital Signature Service cannot 
initiate a connection to the LSCD; the initiative
must originate from the client"....why especially with LSCD? would not 
this also happen in RSCD?...I propose that some rational is provided 
here illustrating what is different regarding this issue with LSCD and RSCD

5. Clause 1.7.1

. First paragraph, last sentence: propose rewording: "The signature is 
returned to the client by the SignResponse (5)".

. Last sentence of last paragraph, explaining Figure 7. "This use case 
can make use of the ETSI stanard for Mobile Commerce (M-COMM) or Mobile 
Signature Service [M-COMM]".
I should review this ETSI spec, but I would say that in M-COMM the 
device generates a complete electronic signature (for instance a cms 
signature) not only the digital signature value...but as I said, I 
should review the text.

6. Clause 1.7.2 Introduction of a User Agent

. It is a bit extrange that the last figure of 1.7.1 shows that the DSS 
Server delegates in a LSCD Signing Server (by the way, this delegation 
is only applicable to LSCD or could also be applicable to RSCD?), this 
1.7.2 starts showing that the DSS client delegates in a User 
Agent...this is the first time it appears....while the DSS server 
delegation appears in 1.7 before 1.7.1....

. Third bullet: "Once the signature has been obtained, it is embedded 
into the the document (4) and the..:", well there are situations where 
the signature is not embedded in the document (CMS, XML detached or 
enveloping signatures)...suggest to reword to something like:
"Once digital signature value has been obtained, the SignResponse is 
built and sent to the user agent (5)".

. In third bullet it is said: "This profile does not specify how the DSS 
server obtains the signature from the user agent: it is left to the 
implementers of the DSS server"
In the last minus one paragraph of this section I read: "This profile 
defines the use of a HTTP user agent together with HTML forms; the HTML 
form initiates a
HTTP POST (from within the user agent) to the specified action location".
After reading the binding it seems to me that this binding is precisely 
about how the DSS server obtains the signature from the User Agent...or 
am I wrong and missunderstood this binding?

7. Clause 1.7.3 An LSCD used by the DSS client

. Suggest rewording to : "For achieving this two-step apprach some 
OptionalInput and OptionalOutput elements need to be introduced
for the SignRequest or SignResponse", before the numbered list.

. Bullet 2, suggest rewording: "After the
DSS client has received the digest as a result of the first SignRequest, 
the LSCD computes the digital signature value and the client incorporate 
it to the aforemtntioned SignRequest using the <dss:SignatureObject> 
element. The DSS server will perform the necessary operations for 
building the final electronic signature, for incorporating it within the 
corresponding document if required, and for returgining it within the 
corresponding SignResponse."

8. Clause 1.7.4. Introduction of a Third Party

. The first sentence seems to say this is an instantiation of examples 2 
and 4...however in the former examples there is one single 
signrequest-signresponse between the dss client and dss server, whereas 
here there are two, being the first one only for getting the correlation 
code...why is so important this correlation code? just for sending the 
same code to the user by two different paths, i.e. the dss server-> dss 
client and third party -> mobile device?...does this means that the 
aferementioned examples 2 and 4 were bad or incomplete?

. Suggest rewording to
"the electronic signature is built and processed based on the signature 
value and the request received (7). The resulting electronic signature 
is returned to the client in the SignResponse (8)"

.The last paragraph says:"The protocol between the Digital Signature
Service and third-party is not specified by this profile, but the DSS 
protocol can be used for this as well,
see for instance Figure 3, “Delegation of the signature creation to the 
LSCD or RSCD”

When I read this I was not sure of the reasons why this is discussed 
within the profile then... but then I read 3.3 Delegation and was a bit 
confused....see my comments at the clause 3.3 below.....


---> Conclusion after reading clause 1.7

. After reading clause 1.7 I think that unless I am wrong there are two 
types of material there:
- Use cases, from 1.7.1 to 1.7.4
- Technical alternatives or something like that, i.e., specific ways of 
giving satisfaction to the needs derived from the use cases...

If this is true, I would suggest to re-structure 1.7 with two sub 
sections one for each of the two types of material so that this is more 
explicit.

. Also, when arrived here the reader is not sure about which of the 
techical alternatives the profile will cover, and in consequence, which 
use cases.....


9. Clause 3.1 User Agent:

. Suggest rewording to:"The Digital Signature Service is responsible for 
the creation of the digital signature value using a (secure)
signature-creation device at the client"

. The text reads:

"The Digital Signature Service must obtain access to the (secure) 
signature-creation device at the client
to create the signature. How the Digital Signature Service implements 
this functionality is not specified
and is not part of the profile; it depends on the capabilities of the 
client and user agent.

A transport binding is proposed that enables the Digital Signature 
Service to use a HTTP agent at the
client to obtain access to the (secure) signature-creation device; see 
Section 4.1, “Transport Binding”."

I would say that the second paragraph contadicts the first one doesn't it?

10. Clause 3.1.2

Second paragraph: suggest rewording to: "No new elements are defined; 
the <dss:SignResponse> contains either the requested electronic signature
according to the [DSSCore] or an error message"

11. Clause 3.2 Two-Step Approach: fix "Approach" to "Approach"

. Suggest rewording to: "the client is responsible for the
creation of the digital signature value using a (secure) 
signature-creation device."

. Note: suggest rewording to: "Maintaining the state at the server is 
only useful...:"

. I am not sure to understand the reason (i) of the note...we can talk 
about that...

11. Clause 3.2.1.1.2 Element <dss:SignatureObject>

. Suggest rewording to : "request to provide the digital signature 
value, obtained from ..."

. Suggest rewording to : "The Digital Signature Service will create the 
electronic signature and process it according to the ..."

12. Clause 3.2.2.2.2 Element <dss:CorrelationID>

. Suggest rewording to : "if and only if the element 
<localsig:ReturnDocumentHash> element was present within the SignRequest
and its MaintainRequestState attribute was set to "true"."


13. Clause 3.3.2.2.1 Element <localSig:ChallengeCode>

. Suggest rewording to: " on the mobile device before it confirms the 
computation of the digital signature value by the mobile device ....".

. Suggest rewording to: "The Digital Signature Service only
creates the requested electronic signature if the response code matches 
the value that was given to the client in
the FIRST response"