200 likes | 306 Views
www.oasis-open.org. OASIS Digital Signature Services . Juan Carlos Cruellas Andreas Kuehne Stefan Drees Ernst Jan van Nigtevecht Frank Cornelis Oscar Burgos. Agenda. Digital Signature Services (DSS): Mission statements of DSS* Technical Committees. Offerings / Use Cases:
E N D
www.oasis-open.org OASIS Digital Signature Services Juan Carlos Cruellas Andreas Kuehne Stefan Drees Ernst Jan van Nigtevecht Frank Cornelis Oscar Burgos
Agenda • Digital Signature Services (DSS): • Mission statements of DSS* Technical Committees. • Offerings / Use Cases: • DSS — The Interface to the Signing service. • Signature Validation— Push it to the Cloud ! • As Time goes by — YourSignatures ? • Capable Client Devices — Local Signing ? • Conformance & Interoperability — Upcoming Event
OASIS Digital Signature Services (DSS) TC1: • Mission: • “Defining an XML interface to process digital signatures for Web services and other applications” • Deliverables (A set of OASIS standards, in 2007): • Core protocols, elements, bindings and profiles. • OASIS Digital Signature Services eXtended (DSS-X) TC2(successor of DSS TC extending and maintaining DSS). • Mission: • “Advancing digital signature services standards for XML” • Notes: • 1)Completed in 2007 to accommodate for OASIS IPR policy changes2) Created in 2007 operating under OASIS RF IPR mode
OASIS DSS Standards: • The interface to the Signing Services. • Protocols for central Signature Generation services: • No more problems with infrastructure deployments • Support for individual generation delegated • Reduces overhead of key management: • Central server in charge of required tasks • Like e.g. certificate status in Generation. • All details of Signature Policies centralized. • Enables centralized auditing.
Verification — Push it to the cloud ! • DSS OASIS Standards: • Protocols for central Signature Verification services: • Verification (with all its complexity) ? • Implemented at and Deployed to the server once. • Reduce overhead of key management: • Central server in charge of required tasks ! • Like e.g. certificate status in Validation. • All details of Signature Policies centralized, enables: • Exhaustive (standardised) validation reports • Log of all validation processes and results • Caching (of CRL, OCSP, TSL, ...) !
As Time goes by — Your signatures ? • DSS capable central Servers take care ! • DSS OASIS Standards: • Protocols for central Signature Upgrade services: • A) You may send a signature and request that: • it is time-stamped with a signature time-stamp • Or — if it already has one — cf. B • B) You may request to: • include in the signature all the validation material (OCSP responses, certificates in the certification path, etc.) • and then time-stamp this “bundle” for achieving a long-term signature.
Personal key pairs must be controlled personally ? • Yes, of course ! • But all the boringandburdensome rest of the “signing party” … ? • No, Thanks ! • Delegate“impersonaltasks”involved to server ! • DSS-X TC is working on such a standard: • “Local Computation of Signature Values”
Finally, what if you want to check if your server: • Interoperates well with other Implementations ? • Complies to DSSStandards ? Yes, Please ! • DSS-X TC is Scoping, Preparingand Organizing: • Remote Event where participants will be able to: • Test their servers Conformity: • With a subset of the DSS protocols • Test the Interoperabilityof their Servers • With all other participating Servers
Useful information: • DSS-X TC Public page: • https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=dss-x • Raise comments sending an email to: • dss-x-comment@lists.oasis-open.org • Access the documents archives at: • https://www.oasis-open.org/committees/documents.php?wg_abbrev=dss-x
DSS concept. Conventional approach • Deploy key to each user • Handle Interface to all PKI functions • Security depends on user
DSS concept. DSS approach Internal user Authentication & authorisation Directory System PKI CertificateManagement DSS Server
classical DSS-domain new DSS (X) http://www.eid-stork.eu/ ISO/IEC 24727 / CEN TS 15480 („European Citizen Card“) DSS also forms the basis for the emerging standard eID-framework ?
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.
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.
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.
DSS-X overview • ebXML Messaging Transport Binding for DSS. • Guidance: cross-matrix for existing profiles joint usage
Current status of specifications • Committee Specifications: • Profile for requesting generation and/or verification of visible signatures. • Profile for generation of a multi-signature verification report providing detailed information on the signature verification process. • ebXML Messaging Transport Binding for DSS.
Additional activities • The DSS-X is defining an interoperability event on DSS and DSS-X specifications: • Contacts between OASIS and ETSI for jointly organize a formal remote interoperability event. • DSS-X TC members are completing a the first version of the test suite. • ETSI would provide a portal supporting the conduction of remote interoperability events. • Initial plans: to be ready for making such event during the first half of 2011.
Additional activities • The DSS-X has started the production of a cross-matrix for clarifying joint usage of the differen DSS and DSS-X profiles.