Practical Digital Signature Issues. Paving the way and new opportunities. Juan Carlos Cruellas – DSS-X co-chair Stefan Drees - DSS-X co-chair Juan Carlos Cruellas – DSS-X co-chair Stefan Drees - DSS-X co-chair

n Paving the way (I): l OASIS DSS Standards. Protocols for central services providing signature generation AND verification. n Avoid problems of deployment of infrastructure required to support individual generation n All the complexity of verification implemented and deployed once at the server. n Reduces overhead of key management: the central server takes care of the required tasks on certs status in both generation and verification. n All the details of the policy for the signatures centralized. n May keep logs of the verification processes and results.

DSS concept. Conventional approach n Deploy key to each user n Handle Interface to all PKI functions n Security depends on user

PKI Certificate Management Directory System Internal user Authentication & authorisation DSS concept. DSS approach

DSS also forms the basis for the emerging standard eID-framework DSS (X) ISO/IEC / CEN TS („European Citizen Card“) ? classical DSS-domain new

n OASIS Digital Signature Services TC produced a set of OASIS standards, including the core protocols and a number of profiles. n When IPR modes changed, it was closed. n New OASIS Digital Signature Services eXtended TC created operating under OASIS RF IPR mode.

l Ebxml Messaging Transport Binding for DSS. n Specifies how DSS messages are encoded and carried using OASIS ebXML Message Service (Ebxml MS). n Ebxml MS: designed for supporting e-business. Communities using it as regular transport mechanism, may use this binding. n Robust channel between DSS clients and servers. n Make use of all the Ebxml MS features, including asynchronous messaging. l Profile for managing visible signatures. n Need to display (mostly in signed documents) information on the digital signatures to human beings. Parts of this information may also be signed. n Aims at defining mechanisms enabling clients interacting with DSS servers, to incorporate this visual information in the created signatures.

n In verification, DSS servers should be able to also verify some of the displayed information. l Profile for supporting centralized encryption/decryption. n Aims at providing protocols for requesting centralized encryption/decryption operations. n Works with CMS ContentInfo and with elements (binary and XML documents). n Allows to request encryption/decryption of only certain parts of a document. n Allows to request encryption for different intended recipients and operate with the corresponding encryption keys. n The combination of encryption and signature is also an issue for this profile.

l Profile for detailed individual verification reports. n Aims at incorporating the capability of reporting individually on each signature found in a document. Also aims at incorporating in each report relevant details of the verification process. n Business requirement: log the details of the verification process, including the certificates whose status were checked, the time-stamps verified, the CRLs checked, the OCSP responses requested and checked, attribute certificates verified, commitment endorsed by the signer, etc…. And this for each signature found in the signed document. l Profile for signed verification responses. n Aims at allowing to DSS clients to request that the verification response is actually signed by the verifying server. n Business requirement: to get responses that may be seen…

n …as signed receipts of the verification of a certain signed document. l Profile for handling signature policies. n Aims at allowing clients to request generation/verification of a digital signature following a certain set of rules (signature policy), and also allowing servers to report on the signature policy used for verifying certain signatures. n Business requirement: different documents may require different types of signatures, generated and verified following different rules and processes. This information is the signature policy. A server may be able to operate under different policies and allow to clients to select the suitable one.

l Analysis of inter-relationships among existing profiles. n Requirement: the number of different DSS profiles requires the production of a document explaining their inter- relationships in order to make a right usage of them. n Paving the way (II): Interoperability events: l Standards more and more complex. Interoperability is an issue. l Interoperability tests: n Very useful for progressing towards interoperability. n Provide feedback to the Standardization Bodies from actual implementers, helping in getting better standards (identify wrong or ambiguous parts, identify new requirements, etc)

l Face to face: XML Sec maintenance WG in l BUT now ALSO REMOTE interoperability events. n ETSI owns a portal supporting remote interoperability tests on XAdES signatures. It has conducted two Remote Interoperability events on XAdES (high figures of participation from Europe and Asia) and organized a third one for next year on XAdES and CAdES. See details at n l Also former DSS TC organized a restricted interoperability test between the TC members.

n New coming areas for digital signatures include trusted services supporting electronic business, with specific requirements on the signatures. One example: l “Registered Electronic Mail”. ETSI is about to publish its Technical Specification TS : “Registered Electronic Mail (REM): Architecture, Formats and Policies”. l REM: an “ enhanced form of mail transmitted by electronic means ( ) which provides evidence relating to the handling of an including proof of submission and delivery “. l This TS specifies a generic architecture for the provision of this type of services, proposals for formats of signed evidences and requirements on the corresponding digital signatures. This spec also acknowledges the existence of centralized services for generation and verification of digital signatures for evidences (DSS set of protocols).