[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dss-x-comment] DSS2 SignatureAlgorithm (ETSI STF 539)
Hi Henrik,
at our last TC call we discussed the DSS-X core 2.0 related topics your
pointed out:
"DSS2 defines the ServicePolicy and AppliedPolicy
elements. Are you planning on including an element for
SignaturePolicy too?".
The view of the TC is that we expect the SignaturePolicy to be a part of the ServicePolicy and we don't see proper way to split these aspects. There will be the danger of overlapping and contradiction of separate policies. Could you provide additional use cases / reasoning for a separation?
"The SignatureActivationData (SAD) element in DSS2
is defined to only contain a string value, meaning that the SAD can
be in any shape or form. How would the DSS service know what kind of
SAD is provided? Would it make sense to include an attribute on the
SAD element that can be used as a hint to the DSS service on how the
SAD should be interpreted? Perhaps a simple
type/issuer/provider/format attribute on the SAD?"
The TC considers the SAD as not required to be a core element (anymore). E.g. the ChipGateway protocol does not take advantage of the SAD element, so we decided to drop this element from core. Specific profiles are of course free to re-introduce it (as a simple string or as a more complex structure)
"The SignatureAlgorithm element is defined as a
string type. How can we specify the use of the RSA-PSS signature
algorithm which may need additional parameters, such as salt length
and trailer field?".
The view of the TC is that maybe used as a coarse grained hint regarding the signing algorithm to be used and we don't see an advantage in expanding the client influence on server side processing. Could you provide additional use cases / reasoning for expanding the SignatureAlgorithm elemnt?
FYI: Here is the link to the latest version of the DSS-X core 2.0 draft:
https://www.oasis-open.org/committees/document.php?document_id=63126&wg_abbrev=dss-x
Greetings,
Andreas
> Hi Andreas,
>
> Thank you for your response. We have a follow-up question regarding
> signature policy:
>
> DSS2 defines the ServicePolicy and AppliedPolicy elements. Are you planning
> on including an element for SignaturePolicy too?
>
> Best regards,
>
> /Henrik
>
> -----Original Message-----
> From: Andreas Kuehne [mailto:kuehne@trustable.de]
> Sent: den 9 maj 2018 12:35
> To: dss-x-comment@lists.oasis-open.org
> Subject: Re: [dss-x-comment] DSS2 SignatureAlgorithm (ETSI STF 539)
>
> Hi Henrik,
>
> my overall vision of a DSS server is that it provides a functionality within
> a given scope and that's what the server and client agree upon.
> This scope may be expressed quite obviously by a ServicePolicy. Once a
> client requests e.g. a qualified seal, the server chooses a reasonable way
> to fulfill this request within the given requirements. The client usually
> isn't aware of all the details. If the client has more specific requirements
> regarding the used algorithm and its parameters it seems to me that initial
> contract between the client and server wasn't specific enough.
>
> The intention of the SignatureAlgorithm optional input is to give the server
> a hint regarding the expected group of signature algorithms. The explicit
> provisioning of algorithm parameters wasn't intended. If the parameters are
> included into the interface it will introduce a lot of additional
> complexity. Not only in terms of schema size, but also in terms error
> handling. And the expected lifetime of the standard will degraded due to new
> upcoming algorithms for signing, hashing and padding and their parameters.
>
> Nevertheless, if you consider explicit parameters as a important requirement
> then now it's the best point in time raise your request as DSS 2.0 is still
> in the Committee Draft phase.
>
> Greetings,
>
> Andreas
>> Hi,
>>
>>
>>
>> We are working in the ETSI STF 539 about protocols for server signing
>> and have a question about the SignatureAlgorithm element in DSS2.
>>
>>
>>
>> The SignatureAlgorithm element is defined as a string type. How can we
>> specify the use of the RSA-PSS signature algorithm which may need
>> additional parameters, such as salt length and trailer field?
>>
>>
>>
>> Best regards,
>>
>> Hälsningar/Regards/Grüße - Henrik
>>
>>
>>
>>
>> Henrik Löfgren, CTO
>> <mailto:anders@comfact.com> henrik@comfact.com
>> Tel: +46 (0)31 13 53 15 Mobile: +46 (0)768 15 98 11
>> <http://www.comfact.com/> www.comfact.com
>>
>>
>>
>>
>>
>>
> --
> Andreas Kühne
> phone: +49 177 293 24 97
> mailto: kuehne@trustable.de
>
> Trustable Ltd. Niederlassung Deutschland Gartenheimstr. 39C - 30659 Hannover
> Amtsgericht Hannover HRB 212612
>
> Director Andreas Kühne
>
> Company UK Company No: 5218868 Registered in England and Wales
>
>
>
> --
> This publicly archived list offers a means to provide input to the OASIS
> Digital Signature Services eXtended (DSS-X) TC.
>
> In order to verify user consent to the Feedback License terms and to
> minimize spam in the list archive, subscription is required before posting.
>
> Subscribe: dss-x-comment-subscribe@lists.oasis-open.org
> Unsubscribe: dss-x-comment-unsubscribe@lists.oasis-open.org
> List help: dss-x-comment-help@lists.oasis-open.org
> List archive: http://lists.oasis-open.org/archives/dss-x-comment/
> Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=dss-x
> Join OASIS: http://www.oasis-open.org/join/
>
>
> --
> This publicly archived list offers a means to provide input to the
> OASIS Digital Signature Services eXtended (DSS-X) TC.
>
> In order to verify user consent to the Feedback License terms and
> to minimize spam in the list archive, subscription is required
> before posting.
>
> Subscribe: dss-x-comment-subscribe@lists.oasis-open.org
> Unsubscribe: dss-x-comment-unsubscribe@lists.oasis-open.org
> List help: dss-x-comment-help@lists.oasis-open.org
> List archive: http://lists.oasis-open.org/archives/dss-x-comment/
> Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=dss-x
> Join OASIS: http://www.oasis-open.org/join/
>
>
--
Andreas Kühne
phone: +49 177 293 24 97
mailto: kuehne@trustable.de
Trustable Ltd. Niederlassung Deutschland Gartenheimstr. 39C - 30659 Hannover Amtsgericht Hannover HRB 212612
Director Andreas Kühne
Company UK Company No: 5218868 Registered in England and Wales
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]