OASIS Digital Signature Services
www.oasis-open.org
Juan Carlos CruellasAndreas Kuehne
Stefan DreesErnst Jan van Nigtevecht
Frank CornelisOscar 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 — Your Signatures ? 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 changes 2) 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 boring and burdensome rest of the “signing party” … ? No, Thanks !
Delegate “impersonal tasks” 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 DSS Standards ? Yes, Please !
DSS-X TC is Scoping, Preparing and Organizing: Remote Event where participants will be able to:
Test their servers Conformity: With a subset of the DSS protocols
Test the Interoperability of 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: [email protected]
Access the documents archives at: https://www.oasis-open.org/committees/documents.php?
wg_abbrev=dss-x
Q&A
DSS concept. Conventional approach Deploy key to
each user Handle Interface
to all PKI functions
Security depends on user
PKI CertificateManagement
Cert.
CRL.
Timestamp
Directory
Archiving
PurchasingSystem
Registration
RevocationCert,CRL.(1)
(2)
(2)
(3)
(3)
(4)
(5) (4)
(5)
PKI CertificateManagement
DirectorySystem
Internal userAuthentication &
authorisation
DSS concept. DSS approach
DSS Server
DSS also forms the basis for the emerging standard eID-framework
DSS (X)
ISO/IEC 24727 / CEN TS 15480
(„European Citizen Card“)
?
http://www.eid-stork.eu/
classical DSS-domainnew
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.
Recommended
