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: [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.|

  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}
Â


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



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