[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (DSSX-30) Public Comment 201809c00001s06
[ https://issues.oasis-open.org/browse/DSSX-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefan Hagen updated DSSX-30:
-----------------------------
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|http://lists.oasis-open.org/archives/dss-x-comment/201809/msg00001.html]Âper attachment with accessibility issues (word file)
{quote}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
{quote}
h2. 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.|
|
was:
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|http://lists.oasis-open.org/archives/dss-x-comment/201809/msg00001.html]Âper attachment with accessibility issues (word file)
{quote}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
{quote}
h2. 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.|
> Public Comment 201809c00001s06
> ------------------------------
>
> Key: DSSX-30
> URL: https://issues.oasis-open.org/browse/DSSX-30
> Project: OASIS Digital Signature Services eXtended (DSS-X) TC
> Issue Type: Bug
> Affects Versions: PRD01
> Reporter: Andreas Kuehne
> Priority: Major
> Labels: PRD01_COMMENT, TC_ESI
>
> 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|http://lists.oasis-open.org/archives/dss-x-comment/201809/msg00001.html]Âper attachment with accessibility issues (word file)
> {quote}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
> {quote}
> h2. 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.|
> |
--
This message was sent by Atlassian JIRA
(v7.7.2#77003)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]