Re: [dss-x] Comments to dss extension local signature computation 2013-06-19

[Ernst Jan van Nigtevecht <ejvn@sonnenglanz.net>]

The feedback can be found inline, at "EJ >>"

Regards

Ernst Jan
On 7-7-2013 14:07, Juan Carlos Cruellas wrote:
> Dear all,
>
> Below follow some comments on the referenced draft:
>
> General comment: although the concept of RSCD is established  the 
> document does not actually seem to deal with this kind of situation, 
> at least in the clauses specifying the protocol...should not then 
> there be some kind of warning or note about that? unless I have missed 
> something.
>
> Page: 5.
> Clause 1.2 Abbreviations
> Comment: not sure about the definition of SSCD: the term seems to be 
> identical to the one coined by the EU Signature Directive...and there 
> the requirements seem to be others...I would avoid to use the same 
> term if something different or with different requirements is meant or 
> not re-define the term if the same concept is trying to be 
> used...moreover, for adding more issues to be dealt with if this term 
> is used, we have the new draft regulation that also deals with this 
> term...
EJ >> The term SSCD is used only in relation to the EU Signature 
Directive. I do not have other contexts/definitions in mind. Do you 
propose to remove the term?


contexts/definitions in mind.
> Page 8.
> Clause 1.7
> Figure 2: in all the rest of figures, the circle representing the 
> server contained information of the processes that take place 
> internally (compute digest, embed digital signature into document...), 
> but nothing is indicated here...should not there be such an information?
EJ >> Good point; included the info to make it consistent with the rest.

> Page 9.
> Clause: 1.7.
> Third paragraph in the page details a flow from step (1) to (5) which 
> actually corresponds to figures 4 and 5 but not to figure 3... see the 
> next comment...I would say that there might be an error in figure 3?
EJ >> Indeed, it was an error in the image. Corrected.

> Page 9.
> Clause: 1.7.
> Figure 3. There are two steps (3)...maybe the arrow that goes from the 
> server to the client should have a (5)? this would make this figure to 
> match the process sketched in third paragraph of page 9...
EJ >> It was a type error indeed. The dss:SignResponse must be "(5)". 
Corrected.

> Page 11.
> Clause 1.7.1.
> Before the bulleted list with number, I miss some text that actually 
> presents the bullets below....something like "For achieveing that, the 
> following elements are needed in some of the SignRequest and 
> SignResponse of the flow"...or so...
EJ >> Agree. Some 'glue' added :-)
"For achieving this some OptionalInput and OptionalOutput elements are 
introduced for the SignRequest or SignResponse."


> Page 11.
> Clause 1.7.2
> First sentence: "is introduced to established" may be should read "is 
> introduced to establish a..."
>> Yes indeed. Corrected.

> Page 14.
> Clause 3.1.1.1.1.
> Not sure to completely capture the implications of the sentence "(i)in 
> case the Digital Signature Service has to maintain the state of the 
> requests for certain document types, such as PDF, "....what is the 
> actual difference with regards the (ii) afterwards? in the end is 
> about sending only once the document...and why only for certain 
> document types? what is actually here the relevant point?
EJ >> It's something that I learned/understood from other vendors that 
create signatures in pdf documents. It has to do with the way the 
signature info is created and space is reserved in  the pdf. Creating 
this a second time will not always result into the same hash value; 
therefore, the state of the document has to be maintained. I will 
collect some more info about this and put it on the mailinglist later 
this week.

> Page 15.
> Clause 3.1.2.2.
> Would not the text "No additional clauses are required..." be better 
> worded "No additional requirements are specified ....."?
EJ >> That's ok. Text changed.

> Page 16.
> Clause 3.2.1
>
> Text: "The element <dss:inputDocuments> MUST  be present and contains 
> the document..."... I think that a better wording would be:
> "he element <dss:inputDocuments> MUST  be present and MUST contain the 
> document..." as this seeems to me to be a formal requirement.
EJ >> Ok. But then we have to look to the other wordings as well. 
Sometimes I use
"the element ... MUST be used ..."
or
".. MUST be provided ...".
Then these should all be rewritten into "... MUST be present and MUST 
contain ...".

> Page 17.
> Clause 4.
> Text in second paragraph: "This is not (yet) profiled in this 
> document". The (yet) seems to indicate that there will be some 
> profiling in the final version of the document...if so, I would 
> suggest to say it explicitely...
EJ >> Agree. Removed "(yet)"  from the text.

> Hope this helps
>
> Regards
>
> Juan Carlos.
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that 
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php