Topics for Mondays agenda

[Andreas Kuehne <kuehne@trustable.de>]

Hi TC members,

I received several comments regarding the current draft of the core document that I would like to discuss on Monday:

• Juan Carlos: The term 'Update Signature' as used e.g. in element 'ReturnUpdatedSignature' is replaced within ETSI with the term 'Augment Signature' to explicitly state the addition of unsigned properties. In addition to this 'real' augmentation the DSS version 1.0 of the core explicitly mentions the producing a new signature on the same documents as an 'update'. I would consider this an outlandish use case and would propose to use the term 'augmentation' and narrow the functionality down to adding unsigned properties.

• Henrik Löfgren: "DSS2 defines the ServicePolicy and AppliedPolicy elements. Are you planning on including an element for SignaturePolicy too?". Due to my understanding the SignaturePolicy is a subset of the ServicePolicy, so already covered.
  

• Henrik Löfgren: "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?" Do we need meta information on SAD? Due to my understand producer and consumer of SAD implicitly agreed upon the content of the SAD. Or is it intended to be interchanged in a standardized way between arbitrary parties? Would an additional mime type do the job? Or go for the Base64DataType?
• Henrik Löfgren: "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?". Due to my opinion the DSS is service interface, not a remote API to openSSL or tools alike. So I woukd not like to expose each and every detail on the interface. Especially I would avoid structures that will surely expand over time!

See you on Monday,

Andreas

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