Practical Digital Signature Issues. Paving the way and new opportunities.

1. www.oasis-open.org Practical Digital Signature Issues.Paving the way and new opportunities. Juan Carlos Cruellas – DSS-X co-chairStefan Drees - DSS-X co-chair Marta Cruellas, CATCERT Pim van derEijk, Sonnenglanz Consulting DetlefHuehnlein, Fed. Ministry of the Interior, Germany EzerFarhi, ARX Andreas Kuehne KonradLanz, Austria Federal ChancellryClements Orthacker., A-SIT, Zentrum fur sichereInformationst

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

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

4. DSS concept. DSS approach Internal user Authentication & authorisation Directory System PKI CertificateManagement DSS Server

5. DSS also forms the basis for the emerging standard eID-framework classical DSS-domain new DSS (X) http://www.eid-stork.eu/ ISO/IEC 24727 / CEN TS 15480 („European Citizen Card“) ?

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

7. Ebxml Messaging Transport Binding for DSS. • Specifies how DSS messages are encoded and carried using OASIS ebXML Message Service (Ebxml MS: transport mechanism for e-business ). • Binding for robust channel between DSS clients and servers and ebxm features (i.e. asynchronous messaging). • Profile for managing visible signatures. • Need to display (mostly in signed documents) information on the digital signatures to human beings, parts of which may also be signed. • Clients will instruct servers to incorporate this visual information in the created signatures. Servers will also verify this signed visual information. • Profile for supporting centralized encryption/decryption. • Aims at providing protocols for requesting centralized encryption/decryption operations (CMS and XML Encryption). • Combination of encryption and signature.

8. Features: encryption/decryption of ¡parts of a document, encryption for different recipients, etc. • Profile for detailed individual verification reports. • Individually report on each signature found in a document and incorporation in each one relevant details of the verification process, satisfying the business requirement of logging them. • Profile for signed verification responses. • Aims at allowing to DSS clients to request that the verification response is actually signed by the verifying server. • Responses that may be seen as signed receipts of the verification of a certain signed document • Profile for handling signature policies. • Request generation/verification of a digital signature following a certain set of rules (signature policy). • Different documents may require different types of signatures, generated and verified following different rules and processes. • Analysis of inter-relationships among existing profiles.

9. Paving the way (II): Interoperability events: • Standards more and more complex. Interoperability is an issue. • Interoperability tests: • Very useful for progressing towards interoperability. • Provide feedback to the Standardization Bodies from actual implementers, helping in getting better standards (identify wrong or ambiguous parts, identify new requirements, etc). • Face to face: XML Sec maintenance WG in 2007. • BUT now ALSO REMOTE interoperability events. • 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 • http://xades-portal.etsi.org/pub/XAdES.shtml • Also former DSS TC organized a restricted interoperability test between the TC members.

10. New coming areas for digital signatures include trusted services supporting electronic business, with specific requirements on the signatures.Some examples: • “Registered Electronic Mail”. ETSI is about to publish its Technical Specification TS 102 640: “Registered Electronic Mail (REM): Architecture, Formats and Policies”. http://portal.etsi.org/stfs/STF_HomePages/STF318/STF318.asp • REM: an “ enhanced form of mail transmitted by electronic means (e-mail) which provides evidence relating to the handling of an e-mail including proof of submission and delivery “. • TS: specifies generic architecture for the provision of this type of services, proposals for formats of signed evidences and requirements on the corresponding digital signatures. It also acknowledges the existence of centralized services for generation and verification of digital signatures for evidences (DSS set of protocols). • Signatures in relevant documents formats: new ETSI STF-364 on PDF signatures and Advanced Electronic Signatures (XAdES and CAdES). Among other things, it will profile CAdES and XAdES with the objective of using them for long term signatures within PDF documents framework