Uploaded image for project: 'OASIS Digital Signature Services eXtended (DSS-X) TC'
  1. OASIS Digital Signature Services eXtended (DSS-X) TC
  2. DSSX-30

Public Comment 201809c00001s06: cardinality of ReturnAugmentedSignature

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: PRD01
    • Fix Version/s: csprd02
    • Component/s: Core

      Description

      Comments from TC ESI to OASIS DSS-X TC on DSS-X V2 -  6 of 19 submitted by Liaison Andreas Kuehne on behalf of Sonia Companies via message  201809c00001 per attachment with accessibility issues (word file)

      following steering committee call on 17/09 and addition of 2 other editorial comments, the resulting pre-agreed comments are now for ESI approval for submission to OASIS DSS-X TC by 28 September

      Comment  #6:

      Clause 4.3.5.
       
      COMMENT: The definition of the component ReturnAugmentedSignature allows for multiple occurrences of this component. One could think that this essentially means that in theory one request could order to the server to augment one signature to one level, another signature to another level, and so on. However, the contents of the type AugmentSignatureInstructionType DOES NOT allow to refer to any signature in the request, so in the end it seems as if one would like to request to the server to augment all the signatures in the request to different levels and retrieve them (i.e., would be like requesting to augment one signature to XAdES-B-T level, then to XAdES-B-LT, and then to XAdES-B-LTA, and return the three augmented signatures). In principle, this does not seem to make lot of sense.
       
      ETSI ESI has decided that in one request the ReturnAugmentedSignature will appear ONLY ONE TIME, with ONE URI value and this will mean that the server is requested to augment all the signatures to the identified level, if possible. The rationale behind is to make things easier for the server.
       
      REQUEST: Modify the specification of the ReturnAugmentedSignature and its type to make it compatible with ETSI ESI, i.e., make maxOccurs of ReturnAugmentedSignature =”1”, and specify that the server shall try to augment all the signatures to the level identified in that component.
      CONCLUSION: Pass the comment to DSS-X.
      Clause 4.3.11. AugmentSignatureInstruction.
       
      COMMENT:
      1.      There is a lack of coherence in the names of certain clauses: for instance clause 4.3.5.2 specify an element called ReturnAugmentedSignature, of type AugmentSignatureInstructionType. There is NO component AugmentSignatureInstruction. There are instances of AugmentSignatureInstructionType. Avoid missunderstandings changing the titles of the clauses.
      2.      The name ReturnAugmentedSignatureType, which is the name selected by ESI for the type in TS 119 442, illustrates with much more precission what the type is about than AugmentSignatureInstructionType does.
      3.      The attribute “Type” is misleading and does not match the terminology used in the ENs that define the AdES signatures: the different combinations of properties/attributes receive the name of “level”, not “type”. So, they speak of XAdES level B-B, XAdES level E-BES, etc.
      4.      The attribute “Type” is optional. This essentially means that this attribute could not be present. The document does not provide any specification of to what level the server has to augment the signatures.
       
      REQUEST :
      1.      Change the name of the type AugmentSignatureInstructionType to ReturnAugmentedSignatureType.
      2.      Change the name clause 4.3.11 to “Instances of ReturnAugmentedSignatureType”, the name of clause 4.3.11.1 to Instances of ReturnAugmentedSignatureType – JSON syntax, and the name of clause 4.3.11.2 to Instances of ReturnAugmentedSignatureType – XML syntax
      3.      Change the name of the attribute from “Type” to “Level”.
      4.      Make the attribute (Level) mandatory (required).
       
      ETSI ESI exchanged information with the editors of DSS core v2.0 about the suitability of not using the term upgrade, which the document has done, however the name does not seem the more appropriate. Instead ReturnAugmentedSignature clearly indicates the purpose of the input: it is an order to the server to augment a signature and to return it. AugmentSignatureInstruction is much more ambiguous as the word Instruction can actually be anything…and from the text that specifies this component one always concludes that the goal is that the server augments a signature and returns it to the client.
       
      The request for changing the name of the attribute to Level is even stronger: “Level” is the formalized term used by all the ETSI ENs on signature formats (CAdES, PAdES, and XAdES) for identifying different combinations of incorporated attributes/properties to the signature. Use of “Type” in the DSS-X protocols will certainly generate at least doubts among users of ETSI ENs, which are used to speak of XAdES-BES level signatures, XAdES-B-B level signatures, etc.
      CONCLUSION: Pass the comment to DSS-X.

        Attachments

          Activity

            People

            • Assignee:
              kuehne Andreas Kuehne
              Reporter:
              kuehne Andreas Kuehne
            • Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: