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: Re: [dss-x] Comments to dss extension local signature computation 2013-06-19

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


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


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:

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