OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dss-x message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Comments to local signature computation draft 18 October

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.


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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]